How Crypto Security Actually Works

Public and Private Key Cryptography

Every Bitcoin address and every Ethereum address starts with a single number: a 256-bit random integer called the private key. You can think of it as a number between 1 and 2^256 - a range so large that randomly guessing someone's private key is more improbable than picking a specific atom out of all matter in the observable universe.

From that private key, a corresponding public key is derived using elliptic curve multiplication on the secp256k1 curve. This is a one-way mathematical operation: given the private key, computing the public key takes milliseconds. Given only the public key, computing the private key would take more time than the current age of the universe on every computer on Earth working simultaneously.

Your wallet address is then derived from the public key by running it through two hash functions (SHA-256, then RIPEMD-160 for Bitcoin; Keccak-256 for Ethereum) and encoding the result. The address is what you share publicly. The private key is what you never share.

The word "cryptography" gets thrown around loosely in crypto. What it actually means here is: the security of your funds rests entirely on one premise - that no one can reverse the elliptic curve function to derive your private key from your public address. So far, no classical computer has come close to breaking this. More on quantum computers in Module 6.

The practical implication: your address is safe to share. Your private key is not safe to share with anyone, ever, under any circumstance. Ledger support will never ask for it. MetaMask will never ask for it. There is no legitimate reason for any person or system to need your private key directly.

Seed Phrases and HD Wallets

Managing a raw 256-bit private key - a string of 64 hexadecimal characters - is error-prone. In 2013, the Bitcoin community proposed BIP-39 (Bitcoin Improvement Proposal 39), which encodes private key entropy as a sequence of English words. This is what became the standard seed phrase, also called a recovery phrase or mnemonic.

How BIP-39 Works

The BIP-39 standard uses a fixed wordlist of 2,048 English words. Because 2^11 = 2,048, each word encodes exactly 11 bits of information. The math works like this:

128 bits of entropy from a 12-word phrase is already beyond brute-force with any conceivable classical computer. 24 words provide 256 bits, which doubles the exponent. Most hardware wallets default to 24 words. Both are effectively equivalent in security terms for the foreseeable future.

The most important thing to understand about your seed phrase: it IS your wallet. Not a backup of your wallet. Not a recovery key for your wallet. The seed phrase is the wallet itself. Anyone who has your seed phrase has complete, permanent, irrevocable access to every address and every asset that wallet has ever controlled or will control.

HD Wallets and Derivation Paths

BIP-32 defined Hierarchical Deterministic (HD) wallets, and BIP-44 standardized the derivation path structure. Instead of one seed phrase per private key, one seed phrase generates a tree of deterministic key pairs - potentially millions of addresses across hundreds of blockchains, all from the same 24 words.

The derivation path encodes which address you're using:

This structure is why you can restore your Ledger with a 24-word seed and see all your assets reappear - Bitcoin, Ethereum, Solana, everything. The same seed, applied to the correct derivation paths, always produces the same addresses. The blockchain is permanent; the seed phrase lets you reconstruct the keys that control it.

What the Blockchain Secures vs What It Doesn't

This distinction is where most security thinking goes wrong. The Bitcoin and Ethereum mainnets have never been hacked in the sense of the chain itself being compromised. Every transaction ever recorded remains immutable. The cryptographic foundation is intact.

What the blockchain secures: once a transaction is included in a block and sufficient blocks have been added on top (6 for Bitcoin, 12-15 for Ethereum), that transaction is effectively irreversible. No one can alter it, reverse it, or erase it. This is what "trustless" actually means: you don't need to trust any party because the math enforces finality.

When $1.5 billion was stolen from Bybit in February 2025, the blockchain worked exactly as designed. The transactions were valid. The attacker had obtained the authorization to sign them through a supply chain attack on Bybit's wallet infrastructure. The chain recorded what happened accurately. The security failure was entirely off-chain.

This distinction matters for everything that follows in this course. Every attack covered in Module 4 - phishing, SIM swaps, clipboard hijackers, malicious approvals - targets the human and device layer, not the chain. Understanding where the security boundary actually lies is the prerequisite for every defense in Module 5.

Custodial vs Self-Custody

When you hold crypto on Coinbase, Binance, or Kraken, those companies hold the private keys. You have an account balance in their database. The "crypto" in your account is an IOU from the exchange backed by actual crypto they hold in their own wallets. If the exchange fails, is hacked, or freezes withdrawals, your account balance may be worthless.

When you hold crypto on a hardware wallet, you hold the private keys. The exchange or custodian has no claim over your assets. If Ledger goes out of business tomorrow, your Bitcoin is still yours because your seed phrase works with any BIP-39-compatible software. The hardware is just a secure place to store keys.

The honest advice: most people should use both. Keep trading amounts on regulated exchanges. Move anything you're holding long-term to self-custody. The threshold is personal, but a common framework is: if losing the amount would materially affect your financial situation, it belongs in self-custody. If it's "walking around money" you might trade next week, an exchange is fine.

Encryption Standards in Crypto

Three algorithms underpin most crypto security. You don't need to implement them, but you need to know what each one does and where it's applied.

These three algorithms work together: your seed phrase is protected by AES-256 when stored in a Ledger Live vault. Your address is derived using SHA-256. Your transactions are authorized using ECDSA. The security of the entire system depends on none of these being broken - and none of them have been broken by classical computers. The quantum risk to ECDSA is real but measured in decades, not years. Module 6 covers this in detail.

The Trust Chain: How Firmware Verification Works

The previous section ended with a claim worth examining: your private key never leaves the secure element. That claim only holds if the firmware running on that secure element is the firmware the manufacturer actually signed. Modified firmware could leak signatures, weaken random number generation, or show the wrong destination address on screen while signing a different one. Every reputable hardware wallet defends against this with a chain of trust anchored at the factory.

The manufacturer holds a private signing key offline in a hardware security module. Every firmware release is signed with that key. The corresponding public verification key is burned into the device bootloader at the factory. When you flash a firmware update through Ledger Live, Trezor Suite, or Keystone Studio, the device does not simply accept the binary. The bootloader checks the signature against the embedded public key before executing a single instruction. A signature mismatch and the firmware refuses to load.

Some manufacturers go further. Trezor publishes the entire firmware source code and Docker-based reproducible build instructions. Anyone can compile the firmware themselves and verify the resulting binary hash matches what Trezor distributes. As of 2026, Trezor, Keystone, and BitBox all support reproducible builds. Ledger does not, because BOLOS, the operating system that runs on Ledger devices, is closed source. Ledger instead relies on its Genuine Check protocol: when you connect a Ledger device, Ledger Live challenges it to prove possession of an attestation certificate signed by Ledger and provisioned at the factory. A counterfeit device cannot produce a valid response.

Both approaches solve the same problem with different trust models. Open firmware lets you verify the source matches the binary. Closed firmware with attestation lets you verify the device matches what the manufacturer shipped. Neither approach is inherently weaker. Both depend on the manufacturer signing key staying secure. The threat model that breaks both is the same: a compromise of the manufacturer signing infrastructure. That has not happened to a major hardware wallet vendor as of 2026.

Counterfeit Devices and Supply Chain Attacks

The most common hardware wallet attack does not break the cryptography. It bypasses the trust chain entirely by getting a compromised device into the user's hands before they ever turn it on. Counterfeit hardware wallets sold through third-party marketplaces have arrived pre-loaded with seed phrases the attacker generated and recorded. The buyer powers on the device, sees a valid seed phrase, transfers funds in. The attacker, who has been holding the recovery phrase since manufacture, drains the wallet on the first meaningful deposit.

These attacks have been documented on Amazon third-party listings, eBay, and through cloned versions of less-established brands between 2018 and 2024. The pattern is consistent: the device looks identical to the genuine article, the packaging looks legitimate, and the firmware reports as valid because the trust chain depends on the bootloader public key. A skilled counterfeiter can replicate the visible parts. They cannot replicate the manufacturer signing key, which is why the device defenses described above ultimately work. But that protection only kicks in if the user does something the counterfeit version cannot pass.

Ledger and Trezor both run Genuine Check or attestation routines on first connection. Both will warn you if a device fails verification. But the second rule above does not depend on either company's tooling. It depends only on the user understanding that a fresh device must generate a fresh seed. That single piece of knowledge defeats the most common hardware wallet compromise in the wild.