Copy English

Why

The question "which hardware wallet" is usually answered with a brand, and a brand is the wrong unit. One word stands in for at least four independent supply chains — the silicon and firmware that generate the seed, the application that constructs and signs a transaction for a specific chain, the cryptographic construction that turns a key and a message into a signature, and the logistics that put the box in your hands. Each is built by different people, audited on a different schedule, and fails in a way the other three cannot detect.

One month made that concrete, which is why the criteria below are worth writing down now rather than after a purchase. Coldcard's defect was in the entropy source: a 2021 build-configuration error routed seed generation to a software PRNG instead of the STM32 hardware RNG, leaving roughly 40 bits of effective entropy on Mk2/Mk3 devices, and at least 1,719 BTC across more than 5,200 addresses was swept once someone noticed. Trezor's incident was in logistics: its fulfilment partner ShipMonk was breached and 13,689 customer records were exposed, with no key touched — the asset stolen was a verified roster of people known to hold hardware wallets, complete with delivery addresses. And on 2026-08-25 Ledger patched a critical flaw in its Ethereum application, the layer between the chain's encoding rules and the device's screen. Three manufacturers, three layers, one month, and no overlap between the failures.

That pattern kills the criterion most buyers actually use. "The vendor with no incidents" is not an observable property — it is the absence of a disclosure, which is also exactly what a vendor that does not look, or does not tell, produces. What can be observed is the shape of a disclosure: how long between discovery and patch, whether the root cause is named specifically enough to be checked, whether the affected build range is stated, whether the fix appears in a changelog you can read. Buy the manufacturer whose incident you can read end to end, because the alternative is buying silence and calling it a clean record.

The fourth layer is the one worth staring at, precisely because it did not appear in the month's news. A signature scheme fails without an event: if the same nonce is ever reused across two signatures, the private key falls out by arithmetic, and nothing on the device, the chain or the balance looks unusual until the funds are gone. RFC 6979 exists to remove that failure mode by deriving the nonce deterministically from the key and the message rather than from a random source — which matters most on exactly the devices whose randomness you cannot inspect. A layer that has been quiet for a decade is not evidence that it is sound; for this layer, quiet is what failure looks like.

And there is now a fifth criterion that did not exist a few years ago. The post-quantum deposit-contract draft in irreversible-switch-design is one instance of a broader move: signature schemes are being prepared for replacement, and the technique is to strip out hardcoded assumptions about the scheme rather than to teach systems a new one. A device bought today will outlive the algorithm it ships with. So the question "can this device receive a new signature algorithm as firmware, or is the curve fixed in hardware?" is not a hypothetical — it is the criterion with the longest half-life on the list, and almost nobody asks it at the point of sale.

How it works

One word, four vendors

The four columns are not ranked. They are independent, which is the entire point: an audit of the application says nothing about the RNG, and a flawless RNG does not stop a fulfilment partner from selling your address to a wrench.

The two tests you can run yourself

Sign the same message twice and compare the bytes. Under RFC 6979 the nonce is a deterministic function of the private key and the message, so two signatures over identical input are byte-identical. If they differ, that is not automatically a defect — hedged determinism deliberately mixes in fresh randomness, and it is safer than pure determinism against fault attacks. What the test buys is the right follow-up question: if they differ, which of the two is it? A vendor that cannot answer that in one sentence has told you something.

Supply your own entropy if the device allows it. Rolling dice into the seed does not require trusting the manufacturer's RNG; it requires trusting only that the device mixes your input in rather than discarding it — a far smaller claim, and one the Coldcard defect shows is worth reducing to. The device that refuses user entropy is asking for trust it has no way to let you verify.

Why "no incidents" is the wrong filter

The three failures this month came from three of the four layers and none of them overlapped, so a clean record in one layer is not evidence about the others. Worse, the record itself is not a measurement. An incident count is a disclosure count, and disclosure is a behaviour of the vendor rather than a property of the device.

What a disclosure does reveal, if you read the whole thing rather than the headline, is four things worth scoring: time from discovery to patch, specificity of root cause ("a build-configuration error routed seed generation to a software PRNG" is checkable; "a security issue" is not), whether the affected range is stated, and whether the fix is traceable in public source or a changelog. A vendor that scores well on those has demonstrated the only capability that generalises to the next incident — because there will be one.

The criterion with the longest half-life

irreversible-switch-design reads a draft EIP that prepares the deposit contract for a signature-scheme replacement, and the technique there is instructive here: it works by removing the contract's hardcoded opinion about the old scheme rather than by teaching it the new one. Hardware has the same distinction in a harder form. A device whose curve arithmetic lives in a secure element's fixed instruction set cannot be given a new scheme by firmware; a device that implements signing in updatable firmware can, at some cost in side-channel exposure.

That is a real trade rather than an obvious answer, which is why it belongs on the table as a question rather than as a rule: the device that cannot be updated is also the device that cannot be updated against you. But given that a scheme replacement is now visibly being designed for, a buyer who never asks the question has made the choice by default.

The conclusion that follows from independence

If the four layers are independent across vendors and correlated inside one, then the strongest available control is not a better single device — it is a multisig whose signers come from different manufacturers. A quorum of two devices from one brand shares an entropy path, an app codebase, a signing implementation and a fulfilment partner; a quorum spanning two brands shares none of them. This is the same argument as third-party-blast-radius turned toward hardware: the question is never whether a vendor is trustworthy, it is how far the damage reaches when one turns out not to be.

1 diagram(s) on the live page.

Where it lands in Jayverse

• Wallet: require the five-item checklist before recommending or supporting any hardware signer. Audit date and scope, deterministic-nonce evidence, entropy-path audit, fulfilment/logistics disclosure, and algorithm-upgradeability — score the device, not the brand.
• Rabbit: verify deterministic nonces wherever a mandate/session key signs off-device. Confirm RFC 6979 or hedged determinism is actually used, and add the two-signature byte-comparison as a CI smoke test on any signing path Rabbit depends on.
• Auditor: score any signer or custody vendor's disclosure, not its incident count. Rate time-to-patch, root-cause specificity, and stated affected range — the same rubric Jayverse's own incident-disclosure practice should meet if something in Wallet or Rabbit ever breaks.
• Devnet/Wallet: any Jayverse multisig or treasury key should span independent implementations, not just independent devices of one brand. Correlated layers inside a single vendor share the same failure surface, which defeats the point of a quorum.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

한 달에 세 층이 무너졌다 — 네 번째 층은 조용히 무너진다

Coldcard의 엔트로피 소스, Trezor의 배송 위탁사, Ledger의 이더리움 앱 — 세 제조사가 한 달 안에 각각 다른 층에서 사고를 냈습니다. 브랜드 이름 하나는 실은 네 개의 독립된 공급망이고, 이번 달에 조용했던 층이야말로 무너져도 티가 나지 않는 층입니다.

아직 범위 미정 — 결과물은 구매 후가 아니라 구매 전에 채우는 한 장짜리 비교표입니다. 후보 기기마다 다섯 가지를 찾고, 각 답이 어디서 나왔는지 출처를 같이 적습니다: (a) 실제로 쓰는 체인에 서명하는 앱의 가장 최근 독립 감사와 그 날짜, (b) 서명이 결정적 nonce(RFC 6979)인지 hedged 방식인지, 그리고 그게 주장인지 검증 가능한지, (c) 시드를 무엇이 생성하며 엔트로피 경로가 끝에서 끝까지 감사된 적이 있는지 — 그리고 기기가 사용자 제공 엔트로피를 받는지, (d) 제조사의 물류·배송 위탁사, 구매에 계정과 배송지가 필요한지, 그리고 마지막 사고 공지를 끝까지 읽은 내용, (e) 펌웨어로 서명 알고리즘을 교체할 수 있는지, 아니면 곡선이 실리콘에 박혀 있는지. 다섯 중 둘은 책상에서 바로 시험됩니다: 같은 메시지를 두 번 서명해 바이트 비교, 그리고 기기가 지원하면 주사위 엔트로피 주입. 출처: Coldcard Mk2/Mk3 시드 엔트로피 결함(2026-07), Trezor·ShipMonk 공지(2026-08-13), Ledger 이더리움 앱 수정(2026-08-25, 보도 기준 — 심각도를 옮겨 적기 전에 권고문 원문을 읽을 것).

왜

"어떤 하드웨어 월렛?"이라는 질문에는 보통 브랜드로 답하는데, 브랜드는 잘못된 단위입니다. 단어 하나가 최소 네 개의 독립된 공급망을 대신합니다 — 시드를 만드는 실리콘과 펌웨어, 특정 체인의 트랜잭션을 구성하고 서명하는 애플리케이션, 키와 메시지를 서명으로 바꾸는 암호학적 구성, 그리고 상자를 손에 쥐여주는 물류. 각각을 다른 사람들이 만들고, 다른 주기로 감사받고, 나머지 셋이 탐지할 수 없는 방식으로 무너집니다.

한 달이 그걸 구체적으로 보여줬고, 그래서 아래 기준은 구매 후가 아니라 지금 적어둘 값어치가 있습니다. Coldcard의 결함은 엔트로피 소스에 있었습니다 — 2021년 빌드 설정 오류가 시드 생성을 STM32 하드웨어 RNG 대신 소프트웨어 PRNG로 흘려보내 Mk2/Mk3에 유효 엔트로피 약 40비트만 남겼고, 누군가 알아챈 뒤 5,200개 넘는 주소에서 최소 1,719 BTC가 쓸려 나갔습니다. Trezor의 사고는 물류에 있었습니다 — 배송 위탁사 ShipMonk가 침해돼 고객 13,689건이 노출됐고 키는 하나도 건드려지지 않았습니다. 도난당한 자산은 배송지가 붙은, 하드웨어 월렛 보유자로 검증된 명부였습니다. 그리고 2026-08-25 Ledger가 이더리움 앱의 치명적 결함을 패치했습니다 — 체인의 인코딩 규칙과 기기 화면 사이에 있는 층입니다. 세 제조사, 세 층, 한 달, 그리고 실패들 사이에 겹침이 전혀 없습니다.

이 패턴은 대부분의 구매자가 실제로 쓰는 기준을 무너뜨립니다. "사고가 없는 제조사"는 관측 가능한 속성이 아닙니다 — 그건 공지의 부재이고, 들여다보지 않는 회사나 알리지 않는 회사가 만들어내는 것도 정확히 같은 모습입니다. 관측할 수 있는 것은 공지의 형태입니다: 발견에서 패치까지 며칠인가, 근본 원인이 확인 가능할 만큼 구체적으로 지목됐는가, 영향받는 빌드 범위가 적혀 있는가, 수정이 읽을 수 있는 체인지로그에 나타나는가. 사고를 끝까지 읽을 수 있는 제조사를 사십시오. 대안은 침묵을 사놓고 그걸 무사고 기록이라 부르는 것입니다.

네 번째 층이 노려볼 값어치가 있습니다 — 정확히 이번 달 뉴스에 나오지 않았기 때문에. 서명 방식은 사건 없이 무너집니다: 같은 nonce가 두 서명에 한 번이라도 재사용되면 개인키가 산수로 떨어져 나오고, 자금이 사라질 때까지 기기에도 체인에도 잔액에도 이상해 보이는 게 없습니다. RFC 6979는 nonce를 난수원이 아니라 키와 메시지에서 결정적으로 유도해 그 실패 양식을 제거하려고 존재하고, 난수를 들여다볼 수 없는 기기에서 가장 중요합니다. 10년간 조용했다는 것은 그 층이 건전하다는 증거가 아닙니다 — 이 층에서는 조용한 것이 곧 실패의 모습입니다.

그리고 몇 년 전에는 없던 다섯 번째 기준이 생겼습니다. irreversible-switch-design 의 포스트퀀텀 예치 컨트랙트 초안은 더 큰 움직임의 한 사례입니다 — 서명 방식이 교체될 준비를 하는 중이고, 그 기법은 시스템에 새 방식을 가르치는 게 아니라 옛 방식에 대한 하드코딩된 전제를 걷어내는 것입니다. 오늘 산 기기는 자기가 달고 나온 알고리즘보다 오래 삽니다. 그래서 "이 기기는 새 서명 알고리즘을 펌웨어로 받을 수 있는가, 아니면 곡선이 하드웨어에 박혀 있는가?" 는 가정이 아닙니다 — 목록에서 반감기가 가장 긴 기준이고, 판매 시점에 이걸 묻는 사람은 거의 없습니다.

동작 방식

단어 하나, 공급사 넷

네 칸에는 순위가 없습니다. 이들은 독립적이고, 그게 요점의 전부입니다: 애플리케이션 감사는 RNG에 대해 아무 말도 하지 않고, 완벽한 RNG도 배송 위탁사가 당신 주소를 렌치에게 파는 것을 막지 못합니다.

직접 돌릴 수 있는 시험 두 개

같은 메시지를 두 번 서명해 바이트를 비교합니다. RFC 6979에서 nonce는 개인키와 메시지의 결정적 함수이므로, 동일 입력에 대한 두 서명은 바이트까지 같습니다. 다르다면 그게 자동으로 결함은 아닙니다 — hedged 결정성은 의도적으로 새 난수를 섞고, 고장 주입 공격에 대해서는 순수 결정성보다 더 안전합니다. 이 시험이 사주는 것은 다음 질문을 할 권리입니다: 다르다면, 둘 중 어느 쪽인가? 이걸 한 문장으로 답하지 못하는 제조사는 이미 뭔가를 말한 것입니다.

기기가 허용하면 엔트로피를 직접 넣습니다. 시드에 주사위를 굴려 넣는 것은 제조사의 RNG를 신뢰할 것을 요구하지 않습니다. 내 입력을 버리지 않고 섞는다는 것만 신뢰하면 되고, 이건 훨씬 작은 주장입니다 — Coldcard 결함이 보여주듯 거기까지 줄여둘 값어치가 있는 주장이고요. 사용자 엔트로피를 거부하는 기기는 검증할 방법이 없는 신뢰를 요구하는 것입니다.

왜 "무사고"가 잘못된 필터인가

이번 달 세 건은 네 층 중 셋에서 나왔고 서로 겹치지 않았습니다. 즉 한 층의 깨끗한 기록은 나머지 층에 대한 증거가 아닙니다. 더 나쁜 건, 기록 자체가 측정이 아니라는 것입니다. 사고 건수는 공지 건수이고, 공지는 기기의 속성이 아니라 제조사의 행동입니다.

헤드라인이 아니라 공지를 끝까지 읽으면 점수 매길 것이 넷 나옵니다: 발견에서 패치까지 걸린 시간, 근본 원인의 구체성("빌드 설정 오류가 시드 생성을 소프트웨어 PRNG로 흘려보냈다"는 확인 가능하고, "보안 이슈"는 아닙니다), 영향 범위가 적혀 있는가, 수정이 공개 소스나 체인지로그에서 추적되는가. 여기서 점수가 좋은 제조사는 다음 사고에도 일반화되는 유일한 역량을 보여준 것입니다 — 다음 사고는 반드시 있으니까요.

반감기가 가장 긴 기준

irreversible-switch-design 은 예치 컨트랙트를 서명 방식 교체에 대비시키는 초안 EIP를 읽는 카드인데, 거기 기법이 여기서도 시사적입니다: 그 초안은 새 방식을 가르쳐서가 아니라 옛 방식에 대한 하드코딩된 의견을 걷어내서 작동합니다. 하드웨어에는 같은 구분이 더 어려운 형태로 있습니다. 곡선 연산이 시큐어 엘리먼트의 고정 명령어 집합 안에 있는 기기는 펌웨어로 새 방식을 받을 수 없고, 서명을 갱신 가능한 펌웨어에서 구현한 기기는 받을 수 있습니다 — 부채널 노출이라는 비용을 치르고요.

이건 뻔한 정답이 아니라 진짜 트레이드오프이고, 그래서 규칙이 아니라 질문으로 표에 들어가야 합니다: 갱신할 수 없는 기기는 당신을 향해서도 갱신될 수 없는 기기입니다. 다만 방식 교체가 눈에 보이게 설계되고 있는 지금, 이 질문을 아예 하지 않는 구매자는 기본값으로 선택을 마친 것입니다.

독립성에서 따라 나오는 결론

네 층이 제조사 사이에서는 독립적이고 한 제조사 안에서는 상관되어 있다면, 쓸 수 있는 가장 강한 통제는 더 좋은 기기 한 대가 아니라 서명자를 서로 다른 제조사에서 가져온 멀티시그입니다. 같은 브랜드 기기 두 대로 만든 정족수는 엔트로피 경로·앱 코드베이스·서명 구현·배송 위탁사를 전부 공유하고, 두 브랜드에 걸친 정족수는 하나도 공유하지 않습니다. 이건 third-party-blast-radius 의 논지를 하드웨어 쪽으로 돌린 것입니다: 질문은 결코 "이 공급사가 믿을 만한가" 가 아니라 "믿을 만하지 않은 것으로 드러났을 때 피해가 어디까지 닿는가" 입니다.

1 diagram(s) on the live page.

Jayverse에서의 위치

• Wallet: 하드웨어 서명기를 추천하거나 지원하기 전에 다섯 항목 체크리스트를 요구한다. 감사 날짜와 범위, 결정론적 논스 증거, 엔트로피 경로 감사, 물류·이행 공개, 알고리즘 업그레이드 가능성 — 브랜드가 아니라 기기를 채점한다.
• Rabbit: mandate/세션키가 오프디바이스에서 서명하는 모든 지점에서 결정론적 논스를 검증한다. RFC 6979나 hedged determinism이 실제로 쓰이는지 확인하고, Rabbit이 의존하는 서명 경로에 두 번 서명해 바이트를 비교하는 테스트를 CI 스모크 테스트로 추가한다.
• Auditor: 서명·커스터디 벤더를 사고 건수가 아니라 공개 문서로 채점한다. 패치까지 걸린 시간, 근본 원인의 구체성, 명시된 영향 범위를 평가한다. Wallet이나 Rabbit에서 무언가 터졌을 때 Jayverse 자체 공개 관행도 이 기준을 충족해야 한다.
• Devnet/Wallet: Jayverse의 멀티시그나 트레저리 키는 한 브랜드의 서로 다른 기기가 아니라 독립된 구현에 걸쳐야 한다. 한 벤더 안의 계층들은 서로 상관돼 있어 같은 실패 표면을 공유하며, 이는 쿼럼의 취지를 무너뜨린다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑