Gjettet, ikke stjålet: svake private nøkler i 2026

Nøkkelen som aldri var hemmelig

Sent i juli 2026 forsvant rundt 1 816 bitcoin, verdt i overkant av 1,1 milliard kroner, fra mer enn 5 200 adresser knyttet til en av de mest anerkjente kalde lommebøkene på markedet. Eierne hadde gjort alt riktig: de brukte en offline maskinvarelommebok, de signerte aldri en phishing-transaksjon, og de ga aldri fra seg gjenopprettingsfrasen. Likevel ble kontoene tømt, ifølge analyseselskapet TRM Labs. Pengene ble ikke stjålet slik vi vanligvis tenker på tyveri. Nøklene var mulige å gjette fra første stund.

2026 er året da kompromitterte nøkler for alvor gikk forbi feil i smartkontrakter som den vanligste måten kryptoverdier forsvinner på; til sammenligning stjal angripere over 3,4 milliarder dollar (rundt 32 milliarder kroner) gjennom hele 2025, ifølge tall fra Chainalysis omtalt av The Record. Det meste av dekningen handler om tyveri: phishing, blindsignering, skadevare og innsidere. Denne teksten handler om en stillere, men like ødeleggende underklasse: nøkler som er kompromittert allerede fra fødselen. Til dagens kurs koster én bitcoin rundt 822 000 kroner og én ether rundt 26 250 kroner, ifølge CoinGecko (med en dollarkurs på rundt 9,40), så innsatsen er høyere enn noen gang.

Forskjellen er avgjørende. En stjålet nøkkel var en gang hemmelig; en svak nøkkel var det aldri. Og i motsetning til et passord kan du ikke lappe en nøkkel. Fra hjernelommebøker på 2010-tallet til Profanity-katastrofen som rammet handelshuset Wintermute, fra Milk Sad-feilen i åpen kildekode til Randstorm-svakheten som lå skjult i tidlige nettlommebøker: det går en rød tråd gjennom alt sammen, og den er som regel nøyaktig 32 bit lang.

Hva en privat nøkkel egentlig er: 256 bit ren tilfeldighet

En privat nøkkel høres avansert ut, men den er i bunn og grunn bare et tall. For Bitcoin og Ethereum er det et tilfeldig valgt tall på 256 bit. Alt annet, altså den offentlige adressen, signaturene og retten til å flytte midlene, utledes matematisk fra dette ene tallet. Hele sikkerhetsmodellen hviler på en eneste antakelse: at ingen andre kan gjette hvilket tall du fikk.

Og på papiret er den antakelsen knallsterk. Et 256-bits nøkkelrom rommer rundt 2 opphøyd i 256 mulige nøkler, et tall med 78 sifre, langt flere enn det finnes atomer i den synlige delen av universet. Å prøve seg gjennom alle er fysisk umulig, uansett hvor mange datamaskiner du har. Det er derfor kryptografene sier at nøkkelen ikke kan brutkraftes. Men det finstilte forbeholdet er lett å overse: beskyttelsen gjelder bare hvis tallet faktisk ble trukket fra hele rommet. Trekkes det i stedet fra en langt mindre pott, kollapser den effektive sikkerheten fullstendig, selv om nøkkelen fortsatt ser ut som et pent 256-bits tall.

Fagbegrepet er entropi, altså mengden reell tilfeldighet som gikk inn i å lage nøkkelen. Standarden BIP-39, som ligger bak de fleste gjenopprettingsfrasene på 12 eller 24 ord, krever mellom 128 og 256 bit entropi nettopp for at frøet skal være umulig å gjette. Problemet oppstår når et program later som det leverer 256 bit, mens det egentlig bare puttet inn en håndfull. Da har du ikke en nøkkel med 78 sifres sikkerhet. Du har en nøkkel som ser slik ut, men som i praksis kan telles på en ettermiddag.

Stjålet mot gjettet, og hvorfor en nøkkel ikke kan lappes

Det finnes grovt sett to måter å miste kontrollen over en nøkkel på. Den første er tyveri: angriperen får tak i den hemmeligheten du allerede har, gjennom en falsk nettside, en info-stjeler på maskinen din, en manipulert signeringsflate eller ren tvang. Den andre er langt mindre forstått: gjetting, eller rettere sagt gjenberegning. Her rører angriperen aldri ved deg. Han regner seg fram til nøkkelen din fordi verktøyet som laget den snevret inn nøkkelrommet så mye at hele populasjonen av nøkler kan gjenskapes.

En nyttig analogi er en hengelås. Ved tyveri bryter noen seg inn og stjeler nøkkelen din. Ved en svak nøkkel er hengelåsen kjøpt fra en produsent som, uten å si det, bare laget noen tusen forskjellige nøkler til hele serien. Låsen ser robust ut, men en tyv med en pose kopinøkler kan gå gjennom hele nabolaget og prøve seg fram. Du merker ingenting før døra står åpen, og å bytte hengelås til en identisk modell hjelper ikke det minste.

Denne andre varianten er lumsk av flere grunner. Offeret gjorde sjelden noe galt i bruksøyeblikket; feilen lå i selve genereringen, ofte år tilbake. Angrepet er passivt og skalerbart: en angriper kan utlede nøkler for tusenvis av ofre på forhånd, sette opp et skript og bare vente på at en av adressene får inn penger. Og verst av alt, du kan ikke lappe en nøkkel. Når en sårbarhet i et program blir oppdaget, ruller utviklerne ut en oppdatering, og saken er ute av verden. En kompromittert nøkkel forsvinner ikke slik. Selve hemmeligheten er utledet fra en svak prosess, så oppdateringen beskytter bare nøkler du lager i framtiden. De gamle er brent for godt. Den eneste utveien er å lage en fersk nøkkel fra en trygg kilde og flytte midlene over før noen andre rekker det.

Coldcard, sommeren 2026: da den kalde lommeboken ga fra seg tilfeldigheten

Ingen sak illustrerer poenget bedre enn Coldcard-hendelsen. Coldcard er en maskinvarelommebok bygget for bitcoin-purister, en dedikert offline dings hvis eneste jobb er å holde nøkkelen din utenfor internett. Nettopp derfor var sjokket så stort da TRM Labs dokumenterte at rundt 1 816 bitcoin, altså i overkant av 1,1 milliard kroner, ble tappet fra over 5 200 adresser i flere bølger.

Rotårsaken var ikke en genial angriper, men en byggekonfigurasjonsfeil i fastvareversjon 4.0.1, som kom ut allerede i mars 2021. Koden sjekket om maskinvarens tilfeldighetsgenerator var definert, ikke om den faktisk var slått på. Resultatet var at enhetene i det stille falt tilbake på en svak programvaregenerator i stedet for den fysiske entropikilden i brikken. Ifølge TRM kollapset den effektive nøkkelstyrken fra de tiltenkte 128 bitene ned mot bare 40 bit på eldre enheter, lavt nok til å brutkrafte med moderne maskinvare. Alt frø som ble laget mellom mars 2021 og oppdateringen kom, var dermed sårbart, uten at eierne merket noe som helst.

TRM beskriver hendelsen som den største utnyttelsen av en maskinvarelommebok i 2026, og det spesielle er at ofrene ikke hadde noe felles utover valget av enhet og tidspunktet for oppsett. Angriperne trengte verken å nå fram til brukerne eller lure dem til å signere noe; de kunne systematisk utlede kandidatnøkler for enheter satt opp i det aktuelle vinduet og sjekke hvilke adresser som hadde saldo. Da den første bølgen først var i gang, gikk det fort, og flere aktører ser ut til å ha jaktet på den samme svakheten samtidig. Det er den skalerbare naturen ved kompromittering-ved-fødsel i praksis: én feil, tusenvis av ofre, null interaksjon.

Den mest ubehagelige lærdommen ligger i hvordan TRM oppsummerte selve fiksen. «Å oppdatere fastvaren løser problemet for framtidig lommebok-generering, men beskytter ikke lommebøker der frøet ble laget under den sårbare fastvaren,» skriver selskapet. Med andre ord: å installere den nye fastvaren stengte døra for nye ofre, men gjorde ingenting for de allerede genererte nøklene. Den som hadde satt opp sin Coldcard i 2021 og latt bitcoin ligge i fred, kunne fortsatt bli tømt i 2026. Dette er «du kan ikke lappe en nøkkel» i sin reneste form, og det rammet nettopp den gruppen som hadde betalt for ekstra trygghet.

CSPRNG mot PRNG: anatomien til en svak nøkkel

For å forstå hvorfor de samme feilene skjer igjen og igjen, må man skille mellom to slags tilfeldighet. En vanlig pseudotilfeldig generator (PRNG) er laget for fart og for statistisk pen fordeling, ikke for hemmelighold. Kjenner du frøet eller den interne tilstanden, kan du forutsi hele rekken. Den mest brukte er Mersenne Twister, ofte i varianten mt19937. Den er utmerket til dataspill og simuleringer, og livsfarlig til nøkler.

En kryptografisk sikker generator (CSPRNG) er derimot bygget slik at selv om du ser mengder av tidligere utdata, kan du ikke forutsi det neste. Operativsystemer leverer slike, matet av fysisk støy fra maskinvaren. Den sterkeste varianten er en ekte maskinvaregenerator (TRNG) i et secure element, der tilfeldigheten kommer fra fysiske prosesser i selve brikken. Den tilbakevendende synden er å seede en generator med en 32-bits verdi. 32 bit gir bare rundt 4,3 milliarder muligheter, et tall et moderne grafikkort tygger seg gjennom på timer. En «256-bits nøkkel» som egentlig stammer fra 32 bit, har altså 32 bits reell sikkerhet, ikke mer.

Grunnen til at 32-bits frø dukker opp så ofte, er sjelden vond vilje. Mersenne Twister er innebygd i utallige programmeringsspråk og er det første mange utviklere griper til når de trenger et tilfeldig tall. Fungerer koden, ser utdataene tilfeldige nok ut, og testene passerer, er det lett å tro at jobben er gjort. Skillet mellom statistisk tilfeldighet, som mt19937 gir rikelig av, og kryptografisk uforutsigbarhet, som den ikke gir i det hele tatt, er akkurat den typen detalj som forsvinner under tidspress.

Profanity og Wintermute: da forfengelighet kostet en formue

I september 2022 ble handelshuset Wintermute tappet for rundt 160 millioner dollar, i overkant av 1,5 milliarder kroner. Skurken var ikke en avansert smartkontrakt-utnyttelse, men et verktøy kalt Profanity, brukt til å lage såkalte vanity-adresser, altså adresser som starter med et pent mønster. Wintermute hadde en driftsadresse som begynte med hele sju nuller. Den så profesjonell ut. Den var også dødsdømt.

Profanity genererte adresser lynraskt ved å seede sin generator med et 32-bits tall, forklarer The Block. Dermed kunne en angriper med nok regnekraft rett og slett prøve seg gjennom alle mulige frøverdier og gjenskape de private nøklene. Utviklerne bak 1inch hadde advart om nettopp dette på forhånd: ifølge deres anslag kunne en oppstilling på 1 000 grafikkort brutkrafte en hvilken som helst sju-tegns vanity-adresse fra Profanity på rundt 50 dager. Wintermutes toppsjef Evgeny Gaevoy forsikret i etterkant at selskapet fortsatt var solvent, men lærdommen var brutal: den pene adressen var kosmetikk, mens tapet av entropi var totalt. Selv et profesjonelt handelshus med gode utviklere gikk i fella.

Milk Sad, Trust Wallet og Randstorm: de samme 32 bitene om og om igjen

Profanity var ingen engangsfeil. Den samme 32-bits synden dukker opp igjen og igjen, i verktøy folk stolte blindt på. Milk Sad, sporet som CVE-2023-39910, rammet Libbitcoin Explorer (bx), et kommandolinjeverktøy mange utviklere brukte. Versjon 3.0.0 til 3.6.0 lente seg på std::mt19937, altså igjen Mersenne Twister med 32-bits frø. Forskerne bak funnet beskrev det treffende: «Når man kjører bx seed -b 256 for å be om 256 bit uforutsigbar entropi, er resultatet 32 bit høypresis klokketid kjørt gjennom en mikser og utvidet til 256 bit uten at ny informasjon legges til.» Feilen ble utnyttet i det stille fra våren 2023, med en større tappebølge i juli, og over 900 000 dollar (godt over 8 millioner kroner) ble flyttet.

Nettleserutvidelsen til Trust Wallet led av nøyaktig samme mønster i november 2022. Ledgers sikkerhetslaboratorium Ledger Donjon fant at nøkkelgeneratoren brukte mt19937 med ett enkelt 32-bits frø, noe som ga bare rundt 4 milliarder mulige gjenopprettingsfraser, knekkbare på et grafikkort uten at brukeren gjorde noe som helst. «PRNG-en som brukes er en Mersenne Twister, og den bør ikke brukes til kryptografiske formål. Den spesialiserte versjonen mt19937 tar dessuten inn én enkelt 32-bits verdi som frø,» skrev Ledger Donjon. Rundt 30 millioner dollar (rundt 280 millioner kroner) sto i fare. Feilen ble meldt til Binance 17. november 2022 og rettet i løpet av dager, Ledger Donjon fikk en dusør på 100 000 dollar (nær en million kroner) for det ansvarlige varslet, og Trust Wallet lovet erstatning. Slike dusører er blitt en hjørnestein i bransjens forsvar, et tema vi går grundigere inn i under bug bounty-programmene i 2026.

Den eldste og mest omfattende av dem alle er Randstorm. Mange nettlommebøker laget mellom 2011 og 2015 bygde på biblioteket BitcoinJS, som i sin tur lente seg på svak tilfeldighet fra nettleserens Math.random, kode opprinnelig hentet fra et Stanford-prosjekt. Den sårbare koden ble faset ut i mars 2014, men nøklene som allerede var laget, forble svake. Da sikkerhetsselskapet Unciphered avslørte funnet i november 2023, anslo de at opptil 1,4 millioner bitcoin, en beholdning som til dagens kurs ville vært verdt godt over tusen milliarder kroner, kunne være eksponert, skriver Dark Reading. Eksponert er ikke det samme som stjålet, og over en million brukere ble varslet slik at de kunne flytte midlene. Men prinsippet er nådeløst: for hver eneste av disse lommebøkene er det umulig å lappe nøkkelen. Den er svak for alltid.

Hjernelommebøker: nøkkelen du valgte selv

Ikke all svak tilfeldighet kommer fra dårlig programvare. Noen ganger er kilden mennesket selv. En hjernelommebok utleder den private nøkkelen fra en passordfrase du velger og husker, i teorien elegant, siden det ikke er noe fysisk å miste. I praksis er det en katastrofe, fordi mennesker velger forutsigbare fraser. Sikkerhetsforskeren Ryan Castellucci demonstrerte dette på Def Con i 2015 med verktøyet Brainflayer, som ifølge CoinDesk kunne sjekke 130 000 passordfraser i sekundet; for én dollar i regnekraft kunne man teste 560 millioner fraser.

Castellucci fant at nær sagt alle hjernelommebøker som noen gang hadde fått inn penger, kunne tømmes, og han kom under arbeidet tilfeldig over en frase som ga ham 250 bitcoin, som han sporet opp eieren av og ga tilbake. «Det ser ut til å være virkelig, virkelig vanskelig å hindre folk i å velge navnet på hunden sin,» sa han til CoinDesk. Poenget hans om formidling er like relevant i dag: «Du kan skrike fra hustakene at noe er svakt og sårbart, men mange vil bare fornekte det uten et fungerende konseptbevis.» En beslektet katastrofe rammet Android i 2013, da en feil i systemets SecureRandom både ga svake nøkler og fikk enkelte lommebøker til å gjenbruke den samme signaturverdien, noe som lar en angriper regne seg fram til nøkkelen; flere lommebøker ble tømt, og Bitcoin-prosjektet gikk ut med en formell advarsel.

Fellesnevneren: samme feil i et helt tiår

Stiller man hendelsene på rad, blir mønsteret umulig å overse. I over ti år har den samme grunnfeilen gått igjen: en generator snevret inn til rundt 32 bit, en menneskevalgt frase, eller svak tilfeldighet fra en nettleser. Ulike verktøy, ulike tiår, samme brudd.

Hvorfor gjentar det seg? Fordi tilfeldighet er usynlig. En svak nøkkel ser helt lik ut som en sterk; den validerer riktig, signerer riktig og fungerer perfekt helt til noen gjetter den. Vanlige tester fanger den ikke, og selv en grundig kodegjennomgang som bekrefter at logikken er korrekt, sier ingenting om hvor mange bit entropi som faktisk gikk inn i frøet. Det er en påminnelse om at revisjon av kode og revisjon av nøkkelhygiene er to forskjellige ting, et skille vi også berører i dekningen av revisjonsselskapenes rolle. At den samme feilen dukker opp på nytt, er dessuten et velkjent mønster i bransjen; vi har sett det med bro-hackene som gjentar seg av akkurat de samme grunnene.

Slik lages en nøkkel som faktisk er tilfeldig

Den gode nyheten er at problemet er løst på teknisk nivå; det handler om å bruke de riktige verktøyene. En trygg nøkkel skal komme fra en kryptografisk sikker generator matet av operativsystemets entropipott, eller aller helst fra en ekte maskinvaregenerator i et secure element, der tilfeldigheten stammer fra fysiske prosesser i brikken. BIP-39 med fulle 128 til 256 bit entropi er ryggraden. Er du ekstra forsiktig, kan du legge til din egen tilfeldighet: mange maskinvarelommebøker lar deg mate inn terningkast, der rundt 50 kast med en vanlig terning gir de 128 bitene du trenger, helt uavhengig av om du stoler på dingsens interne generator.

På institusjonelt nivå går forsvaret et steg lenger. Med distribuert nøkkelgenerering (DKG) og flerpartsberegning (MPC) lages nøkkelen i biter på flere maskiner samtidig, slik at det ikke finnes noen enkelt kilde til entropi som kan svikte, og ingen enkelt maskin som noen gang holder hele hemmeligheten. Fremvoksende løsninger går mot verifiserbar tilfeldighet, der en enhet kan bevise at frøet faktisk kom fra en god kilde. Samtidig minner Trust Wallet og Coldcard oss om at selv profesjonelle aktører og anerkjente produsenter kan bomme, så leverandøruavhengige tiltak som egen terning-entropi og migrering til smartkontoer med gjenoppretting gir en verdifull ekstra sikkerhetsmargin.

Slik sjekker du om dine egne nøkler er trygge

For en vanlig kryptoeier i Norge er den praktiske sjekklisten kortere enn man skulle tro. Det viktigste spørsmålet er om lommeboken eller verktøyet du brukte til å lage nøkkelen, noen gang har vært omtalt i en advarsel om svak tilfeldighet. Bruker du en av de berørte kildene, er ikke råd om årvåkenhet nok; da må midlene flyttes til en fersk nøkkel laget på en trygg enhet.

• Sjekk om nøkkelen ble laget med et kjent svakt verktøy: Coldcard-fastvare 4.0.1, Profanity, Milk Sad eller bx, Trust Wallet-nettleserutvidelsen, BitcoinJS-baserte nettlommebøker fra før 2015, eller en hjernelommebok.
• Hold fastvaren på maskinvarelommeboken oppdatert, men husk at en oppdatering ikke redder et frø som allerede er svakt.
• Lag nye frø på en anerkjent maskinvarelommebok med secure element, og legg gjerne til egen terning-entropi der det støttes.
• Aldri lag en nøkkel eller frase fra et menneskevalgt passord, en nettbasert generator du ikke kan verifisere, eller et vanity-verktøy.
• Er du i tvil, behandle den gamle nøkkelen som kompromittert: generer på nytt og flytt midlene med én gang, før en skanner rekker det.

Det siste punktet er verdt å gjenta, fordi det bryter med intuisjonen. Ved vanlig tyveri kan du noen ganger sikre kontoen i etterkant. Ved en svak nøkkel finnes ingen etterkant: så lenge midlene ligger på adressen, kan hvem som helst som kjenner svakheten regne seg fram til nøkkelen når som helst. Å vente er ikke et alternativ.

Regulatorisk bakteppe: Finanstilsynet, MiCA og ansvaret for nøkkelen

Hvem bærer ansvaret hvis en svak nøkkel gjør at penger forsvinner? Svaret avhenger av hvem som holdt nøkkelen. Fra 1. juli 2025 gjelder kryptoeiendelsloven i Norge, som gjennomfører EUs MiCA-forordning via EØS-avtalen. Finanstilsynet fører tilsyn med kryptoeiendelstjenesteytere (CASP), altså foretak som blant annet driver handel, veksling og oppbevaring av kryptoeiendeler, og disse må ha fysisk tilstedeværelse i EØS. En forvarer som tar hånd om kundenes tilgangsmidler, har plikt til å sikre disse forsvarlig, og det inkluderer i praksis hvordan private nøkler genereres og lagres.

Overgangen er i full gang. Foretak som var registrert hos Finanstilsynet, kan fortsette å tilby tjenester fram til 30. juni 2026 eller til de har fått eller blitt nektet tillatelse etter det nye regelverket. Norske Firi ble den første plattformen som fikk full CASP-tillatelse etter MiCA, ifølge Finanstilsynet. For en forvarer betyr dette at en Coldcard-lignende genereringsfeil i egen infrastruktur fort blir et tilsynsspørsmål og et erstatningsspørsmål, ikke bare et teknisk uhell.

Men her ligger den viktige grensen for privatpersoner: velger du selvforvaring, altså din egen maskinvarelommebok med ditt eget frø, faller du utenfor CASP-tilsynet. Da er nøkkelhygienen fullt og helt ditt eget ansvar, og ingen forvarer eller regulator står bak deg hvis frøet var svakt. Det er friheten og forpliktelsen ved selvforvaring i samme pakke. Et eventuelt tap kan dessuten være vanskelig å få fradrag for; skattemessig behandling av tapt eller stjålet krypto er et eget spørsmål å ta opp med Skatteetaten i skattemeldingen.

For den som faktisk rammes, er det praktiske bildet nøkternt. Et tap bør meldes til politiet, og alvorlige saker havner gjerne hos Økokrim, men stjålne kryptoverdier krysser landegrenser på sekunder og beveger seg døgnet rundt, så tilbakeføring er sjelden. Sporing gjennom mikser og broer og frysing hos utstedere av stablecoin kan i beste fall hente hjem en brøkdel, slik vi har sett i andre saker. Nettopp derfor er forebygging, altså å sikre at nøkkelen ble laget riktig i utgangspunktet, langt mer verdt enn ethvert forsøk på oppgjør i etterkant.

Kort oppsummert: tilfeldighet er hele forsvaret

Historien om svake nøkler er egentlig historien om en enkelt, undervurdert ingrediens. Kryptografien bak Bitcoin og Ethereum er ubrutt, og et ekte 256-bits nøkkelrom er urørlig. Men matematikken beskytter deg bare i den grad tallet ditt faktisk ble trukket fra hele rommet. Faller entropien til 32 eller 40 bit, er den vakre uknekkbarheten en illusjon, og de siste ti årene viser at feilen skjer om og om igjen, hos amatører og proffer, i programvare og i dedikert maskinvare.

Den praktiske lærdommen er nøktern og oppmuntrende på samme tid. Du kan ikke lappe en svak nøkkel, men du kan velge hvor nøkkelen din kommer fra. Bruk en anerkjent maskinvarelommebok med secure element, legg til egen terning-entropi hvis du vil være helt sikker, hold deg unna vanity-verktøy og hjernelommebøker, og behandle enhver nøkkel fra en tvilsom kilde som allerede tapt. Gjettet, ikke stjålet, er en tittel ingen eier ønsker på sin egen historie, og det fine er at den er fullt mulig å unngå.

Frequently Asked Questions

Hva er en svak privat nøkkel?

En svak privat nøkkel er en nøkkel som er laget med for lite tilfeldighet, altså for lav entropi, slik at mengden mulige nøkler blir liten nok til at en angriper kan regne seg fram til den eller prøve seg gjennom alle. Den ser helt lik ut som en sterk nøkkel, men kan i praksis gjettes.

Kan en kompromittert privat nøkkel repareres eller byttes?

Nei, en nøkkel kan ikke lappes slik som programvare. Når en nøkkel eller kilden som laget den er kjent som svak, er den kompromittert for godt. Den eneste løsningen er å lage en helt ny nøkkel fra en pålitelig kilde og flytte midlene over med én gang.

Er maskinvarelommebøker trygge mot svake nøkler?

Som regel ja, siden en maskinvare-TRNG i et secure element er gullstandarden for tilfeldighet, men det er ingen garanti. Coldcard-saken i 2026 viste at en fastvarefeil i det stille kan slå av maskinvare-entropien. Hold fastvaren oppdatert og legg til egen terning-entropi der lommeboken støtter det.

Hvordan vet jeg om nøkkelen min ble laget med nok tilfeldighet?

Sjekk om lommeboken eller verktøyet ditt finnes i en kjent advarsel om svak tilfeldighet, for eksempel Coldcard v4.0.1, Profanity, Milk Sad og bx, Trust Wallet-utvidelsen, BitcoinJS fra før 2015 eller hjernelommebøker. Er du i tvil, lag et nytt frø på en anerkjent maskinvarelommebok og flytt midlene dit.

Regulerer Finanstilsynet oppbevaring av private nøkler i Norge?

Finanstilsynet fører tilsyn med kryptoeiendelstjenesteytere (CASP) etter kryptoeiendelsloven, som gjennomfører MiCA i Norge via EØS fra 1. juli 2025, og forvarere må sikre kundenes tilgangsmidler, inkludert private nøkler. Men selvforvaring på din egen maskinvarelommebok er ditt eget ansvar og faller utenfor dette tilsynet.

Av Anneke de Vries, senterredaktør for sikkerhet og protokoller i HOGE Wire.