Nyheter

Ledger Zilliqa app-sårbarhet 26.07.2026

Fokusert sikkerhetsanalyse: nonce-feil i Zilliqa Ledger-appen tillater gjenoppretting av privat nøkkel fra ~5 native signaturer – og hva dette betyr for brukere av maskinvarelommebøker i regionen.

Toms Ābeltiņš

26. juli 20266 min lesing

Mellom 19. og 22. juli ble det avslørt at Zilliqa Ledger-appen i årevis har generert svake Schnorr-noncer, noe som tillater gjenoppretting av private nøkler fra rundt 5 native signaturer på sekunder. Hvorfor maskinvarelommeboken ikke beskyttet, hvor mye det påvirker regionen, hvordan børsene reagerte (Upbit: ZIL som forsiktighetsaktivum) og hva som står på overvåkningslisten.

Søndag 26. juli 2026. Dette er en fokusert sikkerhetspublikasjon for et spesifikt segment, ikke en daglig nyhetsoversikt. Årsaken må ærlig talt nevnes: de siste 24-48 timene har det ikke dukket opp noen daterbar, helt fersk primærnyhet i vårt segment – kryptobørser og CASP, maskinvarelommebøker, kryptokort og skatteverktøy for Baltikum og Norden. Imidlertid har det i løpet av uken vært en betydelig hendelse, som vi hittil ikke har dekket, direkte i den andre kategorien av segmentet – maskinvarelommebøker: en kritisk sårbarhet i Zilliqa Ledger-appen som tillater gjenoppretting av brukerens private nøkkel. Kjernen i hendelsen utspilte seg mellom 19. og 22. juli, så vi behandler den som ukens hovedsikkerhetstema med en grundig forklaring, regional kontekst og en overvåkningsliste, snarere enn som "gårsdagens" nyhet.

Hva skjedde

Den 19. juli ble det observert aktivitet på kjeden som indikerte en aktiv utnyttelse; den 21. juli bekreftet Zilliqa-teamet årsaken og stoppet native (ikke-EVM) transaksjoner på nettverket, og den 22. juli publiserte de en formell kunngjøring. Problemet er spesifikt: det påvirker Zilliqas offisielle Ledger-app og måten den genererer Schnorr-signaturer for native Zilliqa-transaksjoner på secp256k1-kurven.

Teknisk sett er feilen i genereringen av nonce (en engangs tilfeldig verdi). Appen genererte 40 byte med tilfeldighet og reduserte resultatet modulo kurveordenen, men kopierte deretter et feil 32-byte område inn i nonce-bufferen – og beholdt åtte null-utfyllingsbyte og forkastet åtte byte med faktisk entropi. Som et resultat var de øverste 64 bitene av hver nonce fastsatt til null (dvs. k < 2¹⁹²). En slik forutsigbarhet er fatal: en angriper med omtrent fem eller flere native signaturer fra samme nøkkel kan gjenopprette den private nøkkelen med standard gitterreduksjonsmetoder – på sekunder, med vanlig maskinvare.

Sårbarheten har eksistert siden 2019 og påvirker kun native, Ledger-signerte Zilliqa-transaksjoner. Den påvirker ikke EVM-kompatible transaksjoner, eller bibliotekene zilliqa-js, gozilliqa-sdk og pyzil. Børsen KuCoin hjalp til med å oppdage problemet ved å spore det.

Hvorfor maskinvarelommeboken ikke beskyttet her

Denne saken er viktig for brukere i vår region nettopp fordi den undergraver den forenklede antagelsen "hvis jeg bruker en maskinvarelommebok, er jeg trygg". Sårbarheten ligger ikke i Ledgers sikkerhetselement eller enhetens operativsystem – den ligger i den spesifikke kryptovalutaens signeringsapp som kjører på enheten. Maskinvarelommeboken lagret nøkkelen isolert på riktig måte, men signaturene den genererte, lekket i seg selv nok informasjon til å gjenopprette nøkkelen.

Den praktiske lærdommen er at sikkerheten til en maskinvarelommebok er like sterk som signeringskoden for hver mynt. Ledger, Trezor, BitBox, Coldcard og Tangem er alle avhengige av separate apper eller fastvaremoduler for spesifikke nettverk, og en feil i den kryptografiske implementeringen – spesielt i nonce-genereringen – kan fullstendig omgå enhetens fysiske isolasjon. Problemer med nonce-gjentakelse og svake noncer er ikke nye; de har historisk sett kompromittert både programvare- og maskinvaresignere. Det nye her er et spesifikt, daterbart tilfelle i et reelt, mye brukt økosystem.

Innvirkning på brukere i regionen

Den direkte innvirkningen i Baltikum og Norden er sannsynligvis begrenset: andelen native Zilliqa-aktiva i private brukerporteføljer i regionen er liten sammenlignet med Bitcoin, Ethereum eller de største stablecoins. Imidlertid er Ledger en av de mest utbredte maskinvarelommebøkene for privat selvforvaring i regionen, og etter utløpet av MiCA-overgangsperioden 1. juli har en del brukere gått over fra børser til selvforvaring. Derfor gjelder den prinsipielle lærdommen bredt, selv om den spesifikke aktivaen ikke gjør det.

For de få brukerne i regionen som faktisk har signert native Zilliqa-transaksjoner med Ledger, er situasjonen alvorlig: hvis det er omtrent fem eller flere slike signaturer fra én nøkkel på kjeden, anses nøkkelen som kompromittert. Den korrigerte appen gjenoppretter ikke sikkerheten for nøkler som allerede er utsatt for signaturer som allerede er registrert på kjeden – en senere korreksjon forhindrer fremtidige signaturer, men opphever ikke tidligere lekkasjer.

Børsreaksjon

Børsen Upbit reagerte strengt, og merket ZIL som et "forsiktighetsaktivum" i både KRW- og BTC-handelspar, stoppet innskudd og uttak, og advarte om at handelsstøtten kunne bli fullstendig avbrutt hvis problemet ikke ble løst raskt. KuCoin, som nevnt, var involvert i å spore årsaken. Verken Zilliqa eller børsene har offentliggjort hvor mange private nøkler som faktisk er kompromittert, eller hva det totale tapet i dollar er. Direkte involvering fra regionale børser er hittil ikke dokumentert, men for regionale brukere som holder ZIL på eksterne plattformer, er det verdt å sjekke de respektive plattformenes kunngjøringer om status for innskudd/uttak.

Overvåkningsliste

Flere spørsmål forblir ubesvarte og er verdt å merke seg de kommende dagene. For det første, utgivelsesdatoen for den korrigerte Ledger-appen: Zilliqa indikerte at en korrigert versjon med full bredde nonce-generering er utarbeidet i samarbeid med Ledger, men utgivelsesdetaljer vil bli kunngjort separat. For det andre, gjenopptakelsen av native transaksjoner på Zilliqa-nettverket og den fullstendige gjenopprettingsprosedyren, som ennå ikke er publisert på tidspunktet for denne artikkelen. For det tredje, om andre børser følger Upbits eksempel med ZIL-restriksjoner. For det fjerde og i større skala – om Ledger eller andre maskinvarelommebokprodusenter implementerer ytterligere kontroller for tredjeparts myntapplikasjoners signeringskode, da denne saken fremhever nettopp dette leddet i tillitskjeden.

Hva skal regionale brukere gjøre

For brukere som har signert native Zilliqa-transaksjoner med Ledger, er Zilliqas offisielle anbefaling å vente på teamets instruksjoner før de foretar seg noe, da feilaktig flytting av midler i et kompromittert miljø kan akselerere tapet av dem. For et bredere publikum som ikke bruker Zilliqa, er den praktiske handlingen konseptuell: hold maskinvarelommebokens fastvare og myntapper oppdatert, følg offisielle sikkerhetskunngjøringer fra produsenter og nettverk, og ikke betrakt en maskinvarelommebok som en absolutt garanti – den beskytter nøkkelen mot eksfiltrering, men beskytter ikke mot feil i signeringsimplementeringen. Diversifisering mellom lommebokmodeller og oppmerksomhet mot offisielle CVE-er og sikkerhetskunngjøringer forblir en fornuftig praksis.

Norriwire Briefing