Ethereum Kald Lagring Uten Blindsignering: 12 Steg

I februar 2025 forsvant rundt 1,5 milliarder dollar i Ethereum fra en børs som trodde nøklene lå trygt i kald lagring. Bybit hadde gjort alt “riktig” på papiret: en multisig-lommebok bygget på Safe, maskinvarelommebøker hos flere signerere, og en prosess der ingen enkeltperson kunne flytte pengene alene. Likevel klarte angriperne å lure signererne til å godkjenne en transaksjon som ga dem full kontroll over 401.347 ETH.

Grunnen handler ikke om svak kryptografi eller et hull i Ethereum-protokollen. Den handler om et problem som har fulgt maskinvarelommebøker siden de første modellene kom på markedet: blindsignering. Denne artikkelen viser hvordan du bygger en Ethereum-oppsett for kald lagring som faktisk tar høyde for dette, med luftgapt signering, uavhengig verifisering av transaksjoner og en testet gjenopprettingsplan. Du får 12 konkrete steg, seks kodeeksempler og en komplett verifiseringsrutine du kan bruke i dag, uansett om du sikrer en privat Ethereum-beholdning eller en DAO-treasury.

Dette er like relevant for nordiske investorer og selskaper som for globale børser. Selvforvaltet oppbevaring av kryptovaluta har blitt vanligere i Norden etter flere år med børshack, og de samme svakhetene i signeringsflyten gjelder uavhengig av hvor i verden lommeboken befinner seg. Prinsippene i denne guiden fungerer likt om du sitter i Oslo, Stockholm eller København, og verktøyene som brukes er de samme globale standardene som resten av bransjen forholder seg til.

Bybit-hacket: hvordan 1,5 milliarder dollar forsvant fra en “trygg” kald lommebok

Ifølge Bybits egen hendelsesrapport ble angrepet utført gjennom et phishingangrep mot signererne i multisig-lommeboken. Grensesnittet i Safe (tidligere Gnosis Safe) ble forfalsket, slik at det viste en helt annen transaksjon enn den som faktisk ble signert. Blockchain-kommentator Wang Yishi beskrev bakgrunnen slik i et intervju: “Problemet var at datamaskinen til en frontend-utvikler hos Safe ble sosialt manipulert, og skadelig kode ble plantet i frontend-en som bare aktiverte seg på Bybit-adresser,” ifølge Odaily.

Det som gjorde angrepet mulig, var at maskinvarelommeboken til signererne ikke klarte å avverge det. Wang Yishi pekte direkte på dette: “Som hell ville ha det, gjorde Ledger blindsignering, den tolket ikke Safe-kontrakten, viste ikke delegatecall-en, og ga ingen advarsel,” ifølge samme kilde. Sikkerhetsekspert Flynn nyanserte bildet noe i etterkant og påpekte at “blindsignering er et problem, men det er ikke hovedmistenkte i dette tilfellet,” ifølge crypto.news. Begge har rett på sin måte: det egentlige inngangspunktet var en kompromittert utviklermaskin, men det som lot angriperne fullføre kuppet uten å bli stoppet av et enkelt signeringsvindu, var mangelen på lesbar verifisering på selve maskinvaren.

En LinkedIn-post fra sikkerhetskommentator Carlos Vendrell Felici oppsummerte konsekvensen presist: “Dette var blindsignering i stor skala,” skrev han i en analyse som ble delt bredt i sikkerhetsmiljøet etter hacket. Poenget er ikke at kald lagring er verdiløs. Poenget er at kald lagring uten evne til å lese hva du faktisk signerer, bare flytter risikoen fra internett-tilkoblingen til grensesnittet du stoler på.

Det som gjør hendelsen ekstra alvorlig er skalaen. Bybit-hacket er blant de største enkelthendelsene i kryptovalutaens historie, og det traff en børs med etablerte sikkerhetsrutiner, egne revisjoner og et team som visste hva multisig var for noe. Hvis et slikt oppsett kunne lures, er det ikke urealistisk at en mindre organisasjon eller en privatperson med tilsvarende arkitektur, men uten samme ressurser til overvåking, hadde vært enda mer utsatt. Det er grunnen til at denne artikkelen ikke bare handler om å kjøpe riktig maskinvare, men om å bygge en hel rutine rundt hvordan du bekrefter det du signerer.

Blindsignering forklart: hvorfor skjermen på lommeboken lurer deg

Blindsignering betyr at maskinvarelommeboken din signerer en transaksjon uten å vise deg hva den faktisk gjør. Du ser gjerne en hash, en rekke tall og bokstaver, men ingenting som forklarer at transaksjonen for eksempel bytter ut hele eierlisten i en multisig-kontrakt. Enheten stoler blindt på dataene den mottar fra datamaskinen eller telefonen, og du stoler blindt på enheten. Ingen av leddene kan faktisk bekrefte at det som vises stemmer med det som skjer på kjeden.

EIP-712 og clear signing

EIP-712 definerer en standard for strukturert, typet data som kan signeres på Ethereum. I stedet for å signere en rå hash, signerer du et objekt med navngitte felt, som “mottaker”, “beløp” og “gyldig til”. Når en lommebok tolker disse feltene og viser dem i klartekst, kalles det “clear signing”. Når den bare viser en hash uten å tolke innholdet, er det blindsignering. Safe-transaksjoner bruker nettopp EIP-712 under panseret, men mange maskinvarelommebøker klarte i 2025 ikke å tolke feltet som beskrev en delegatecall, altså en instruks som lar en kontrakt utføre kode på vegne av en annen. Det var nøyaktig dette hullet Bybit-angriperne utnyttet.

I mai 2026 svarte deler av bransjen på dette. En arbeidsgruppe med lommebokutviklere, sikkerhetsfirmaer og Ethereum Foundations Trillion Dollar Security Initiative lanserte en åpen standard som skal gjøre det slutt på blindsignering, ifølge Ethereum Foundations sikkerhetsblogg. Standarden legger opp til at lommebøker skal kunne tolke og vise strukturerte data konsekvent, ikke bare for enkle overføringer, men også for komplekse multisig- og smartkontraktkall. Frem til den støtten er utbredt i alle enheter du bruker, må du selv bygge inn uavhengig verifisering i rutinen din. Resten av denne artikkelen viser nøyaktig hvordan.

Forskjellen mellom en vanlig overføring og en Safe-transaksjon som endrer selve eierskapet er verdt å forstå konkret. En vanlig ETH-overføring har et “to”-felt som er mottakerens adresse og et “value”-felt som er beløpet, begge enkle å lese selv i et blindt grensesnitt. En transaksjon som endrer eierlisten i en Safe, kaller derimot en funksjon i selve kontrakten, ofte via en delegatecall, og feltet med selve instruksen er kodet som rå bytes. Uten et grensesnitt som tolker denne koden til noe menneskelig lesbart, som “legg til ny eier: 0x…” eller “senk terskelen til 1 av 3”, ser transaksjonen identisk ut med en helt uskyldig oppdatering. Det er nettopp dette gapet som gjør uavhengig verifisering nødvendig, ikke bare et nyttig tillegg.

Forutsetninger: maskinvare og programvare du trenger

Du trenger ikke dyrt utstyr for å bygge dette oppsettet, men du trenger disiplin på hva du installerer hvor. Sett av en hel kveld til første gjennomgang, og planlegg en egen kveld senere til gjenopprettingstesten i steg 12. Kostnaden ligger primært i selve maskinvarelommeboken, mens resten av verktøyene i denne guiden er gratis og åpen kildekode. Sett opp alt utstyret på en ren, dedikert flate før du starter, og hold en enkel loggbok, gjerne på papir, over hvilket steg du er kommet til. Det gjør det langt enklere å plukke opp arbeidet igjen hvis noe avbryter deg midtveis.

En luftgapt maskinvarelommebok som støtter QR-basert signering for Ethereum, for eksempel Keystone 3 Pro eller Keycard Shell
Nyeste stabile firmware for den valgte enheten, lastet ned direkte fra produsentens offisielle nettside, aldri fra en tredjepartslenke
En dedikert datamaskin eller telefon som aldri kobles til internett, brukt kun til å generere og verifisere seed offline
Safe (tidligere Gnosis Safe) som smartkontrakt for multisig-lommeboken, satt opp via safe.global
Python 3.10 eller nyere med bibliotekene web3.py og eth-account installert, til verifiseringsskriptene i denne artikkelen
Node.js 18 LTS eller nyere, hvis du foretrekker en JavaScript-variant av skriptene
En fysisk, offline metode for å lagre seed-frasen, som en metallplate eller papir i en brannsikker safe, aldri en digital fil
Grunnleggende kjennskap til kommandolinjen på bash eller PowerShell

Slik velger du en luftgapt lommebok for Ethereum

Et ekte luftgap betyr at enheten aldri kobler seg til en datamaskin eller telefon via USB eller Bluetooth. Overføring av signeringsdata skjer i stedet via QR-koder eller mikroSD-kort. Standarden de fleste enhetene bruker for dette kalles BC-UR, med en Ethereum-spesifikk utvidelse kalt ERC-4527. Dette lar en Safe-klient generere en QR-kode med transaksjonsdataene, som lommeboken din kan lese med et kamera uten noen kabel involvert.

Enhet	Luftgap-metode	Sikkerhetselement	Egnet for Safe-multisig
Keystone 3 Pro	Kamera + QR (BC-UR/ERC-4527), mikroSD	Sikkert element med inngrepsbeskyttelse	Ja, støtter Safe og WalletConnect direkte
Keycard Shell	Kamera + QR (BC-UR/ERC-4527)	Sikkert element, åpen kildekode-prosjekt	Ja, bygget spesifikt for EVM-kontoer
SafePal S1 Pro	Kamera + QR-kode	CC EAL6+-sertifisert brikke, ifølge produsenten	Ja, støtter flere EVM-kjeder
Coldcard Mk4/Q	Kamera + QR (BC-UR), mikroSD	Dedikert sikkerhetsbrikke	Begrenset, primært bygget for Bitcoin
Foundation Passport	Kamera + QR (BC-UR), mikroSD	Åpen kildekode-firmware	Begrenset, primært Bitcoin-fokusert

Legg merke til at ikke alle luftgapte lommebøker er bygget for Ethereum i utgangspunktet. Coldcard og Foundation Passport er utmerkede valg for Bitcoin, men støtten for Safe-multisig og EVM-kontrakter er fortsatt begrenset. Velg en enhet som er eksplisitt bygget for Ethereum og EVM-kompatible kjeder, og les gjennom produsentens egen dokumentasjon om hvilke datafelt enheten faktisk tolker og viser, ikke bare hvilke den signerer. Hvis du også sikrer Bitcoin, er prinsippene overførbare til vår egen gjennomgang av Bitcoin kald lagring med air-gapped multisig, selv om verktøyene for EVM-kjeder er annerledes.

Grunnen til at USB og Bluetooth svekker et luftgap, er enklere enn den kanskje virker. En kabel eller en radioforbindelse er en aktiv datakanal, og alt som kan sende data begge veier kan i prinsippet utnyttes til mer enn det er tiltenkt, selv om produsenten aldri har hatt til hensikt å tillate det. QR-koder og mikroSD-kort er passive medier. Lommeboken leser dataene den mottar, men kan ikke bli “svart på” eller manipulert over samme kanal i retur uten at det krever fysisk tilgang til enheten. Det er derfor kamera- og korttbaserte metoder regnes som et ekte luftgap, mens en “offline” enhet som fortsatt har en aktiv USB-driver ikke gir samme garanti.

Hold også et øye med produsentens oppdateringstakt. En enhet som ikke har fått en sikkerhetsoppdatering på lang tid, er ikke nødvendigvis utrygg, men det er en indikasjon på at du bør lese gjennom endringsloggen nøye før du stoler på at feltparsingen er oppdatert til dagens standarder. Se etter dokumentasjon på produsentens egen side om nøyaktig hvilke EIP-712-typer og kontraktkall enheten din faktisk tolker, ikke bare en generell påstand om at den “støtter Ethereum”.

Steg 1 til 3: velg og verifiser en luftgapt lommebok

Steg 1: Bestill lommeboken direkte fra produsenten eller en autorisert forhandler, aldri via bruktmarkedsplasser. Kontroller forseglingen når pakken ankommer, og sammenlign den med bildene av ekte forsegling i produsentens dokumentasjon. For flere detaljer om selve mottaks- og oppsettsrutinen, se vår gjennomgang av sikker oppsett av maskinvarelommebok.

Steg 2: Før du tar enheten i bruk, verifiser firmwaren du skal installere. De fleste produsenter publiserer en signaturfil sammen med hver firmware-versjon.

# Last ned firmware og signaturfil direkte fra produsentens offisielle side
curl -O https://din-produsent.example/firmware/latest.bin
curl -O https://din-produsent.example/firmware/latest.bin.sig

# Importer produsentens offentlige PGP-nøkkel, hentet fra samme offisielle domene
gpg --import produsent-public-key.asc

# Verifiser signaturen før du flasher enheten
gpg --verify latest.bin.sig latest.bin

Hvis kommandoen svarer med “Good signature”, er du klar til å installere firmwaren. Hvis den svarer med “BAD signature” eller en feilmelding om ukjent nøkkel, stopp umiddelbart og last ned filene på nytt fra en annen nettverkstilkobling. Flash aldri en firmware-fil du ikke har verifisert. En mer detaljert gjennomgang av selve verifiseringsprosessen finner du i artikkelen om hvordan du verifiserer firmware trygt.

Steg 3: Generer seed-frasen på enheten selv, aldri på en tilkoblet datamaskin. Skriv frasen ned på papir eller stemp den inn i en metallplate, og verifiser den ved å taste den inn på nytt på et andre luftgapt verktøy før du flytter noe verdi til adressen. Denne dobbeltsjekken avdekker de fleste transkripsjonsfeil før de blir et problem. Noter også hvilken derivasjonssti enheten bruker som standard for Ethereum, vanligvis m/44’/60’/0’/0/0, siden dette er informasjonen som ofte glemmes og som blir avgjørende den dagen du må gjenopprette lommeboken på nytt utstyr.

Steg 4 til 6: sett opp Safe-multisig og koble til luftgapt signering

Steg 4: Gå til safe.global og opprett en ny Safe-lommebok på Ethereum mainnet. Legg til adressene fra hver luftgapte enhet som eier. Et vanlig oppsett for privat kald lagring er 2-av-3, mens en DAO-treasury ofte bruker 3-av-5 eller høyere for å tåle at en signerer er utilgjengelig. Styrer du en organisasjons treasury, kan vår gjennomgang av Safe-multisig for DAO-treasury være et nyttig tillegg til denne artikkelen.

Steg 5: Velg terskelen nøye. Et for lavt krav gjør kontoen sårbar hvis en enkelt signerer blir kompromittert, mens et for høyt krav gjør deg sårbar for at pengene låses fast hvis du mister tilgang til for mange enheter samtidig. Test alltid terskelen med en liten transaksjon før du setter den som permanent for et stort beløp. For en familie eller et lite team er 2-av-3 en fornuftig balanse, siden du tåler å miste én enhet uten å tape tilgang, samtidig som en enkelt kompromittert signerer aldri er nok til å flytte penger alene.

Steg 6: Koble den luftgapte lommeboken til Safe-grensesnittet via QR-kode. Safe genererer en EIP-712-strukturert melding for transaksjonen, kodet med BC-UR/ERC-4527-standarden. Under panseret ser den typede meldingen slik ut:

{
  "types": {
    "SafeTx": [
      { "name": "to", "type": "address" },
      { "name": "value", "type": "uint256" },
      { "name": "data", "type": "bytes" },
      { "name": "operation", "type": "uint8" },
      { "name": "safeTxGas", "type": "uint256" },
      { "name": "baseGas", "type": "uint256" },
      { "name": "gasPrice", "type": "uint256" },
      { "name": "gasToken", "type": "address" },
      { "name": "refundReceiver", "type": "address" },
      { "name": "nonce", "type": "uint256" }
    ]
  },
  "domain": {
    "chainId": 1,
    "verifyingContract": "0xDIN_SAFE_ADRESSE"
  },
  "primaryType": "SafeTx",
  "message": {
    "to": "0xMOTTAKER_ADRESSE",
    "value": "0",
    "data": "0x",
    "operation": 0,
    "safeTxGas": "0",
    "baseGas": "0",
    "gasPrice": "0",
    "gasToken": "0x0000000000000000000000000000000000000000",
    "refundReceiver": "0x0000000000000000000000000000000000000000",
    "nonce": 12
  }
}

Legg merke til feltet “operation”. Verdien 1 betyr delegatecall, det samme feltet Ledger-enheten i Bybit-hacket aldri viste til signererne. Hvis enheten din bare viser en hash og ikke feltene i denne strukturen, signerer du fortsatt blindt, uansett hvor luftgapt maskinvaren er.

Steg 7 til 9: test transaksjonen og verifiser uavhengig av grensesnittet

Steg 7: Send alltid en liten testtransaksjon først, for eksempel noen få dollar i verdi, før du flytter hovedbeløpet. Bekreft at pengene ankommer riktig adresse og at hele signeringsflyten fungerer som forventet med alle signererne.

Steg 8: Slå på clear signing der enheten din støtter det, og oppdater firmware regelmessig for å få tilgang til forbedret feltparsing etter hvert som produsentene ruller ut støtte for den nye åpne standarden fra Ethereum Foundation. Sjekk alltid endringsloggen for hver firmware-oppdatering før du installerer den. Hvis enheten din fortsatt bare viser rå hex-data for kontraktkall, betrakt den som et blindsignerings-verktøy uansett hva markedsføringen sier, og legg desto større vekt på steg 9.

Steg 9: Uansett hvor god skjermen på enheten er, bør du aldri stole på et eneste grensesnitt. Beregn transaksjonshashen selv, offline, og sammenlign den med det som vises i Safe-appen og på lommebokens skjerm. Dette er den beskyttelsen som faktisk ville avverget Bybit-scenariet, fordi en forfalsket frontend ikke kan endre en hash du regner ut selv fra rådataene.

from eth_account.messages import encode_typed_data

domain = {
    "chainId": 1,
    "verifyingContract": "0xDIN_SAFE_ADRESSE",
}

message_types = {
    "SafeTx": [
        {"name": "to", "type": "address"},
        {"name": "value", "type": "uint256"},
        {"name": "data", "type": "bytes"},
        {"name": "operation", "type": "uint8"},
        {"name": "safeTxGas", "type": "uint256"},
        {"name": "baseGas", "type": "uint256"},
        {"name": "gasPrice", "type": "uint256"},
        {"name": "gasToken", "type": "address"},
        {"name": "refundReceiver", "type": "address"},
        {"name": "nonce", "type": "uint256"},
    ]
}

safe_tx = {
    "to": "0xMOTTAKER_ADRESSE",
    "value": 0,
    "data": "0x",
    "operation": 0,
    "safeTxGas": 0,
    "baseGas": 0,
    "gasPrice": 0,
    "gasToken": "0x0000000000000000000000000000000000000000",
    "refundReceiver": "0x0000000000000000000000000000000000000000",
    "nonce": 12,
}

typed_data = {
    "types": message_types,
    "domain": domain,
    "primaryType": "SafeTx",
    "message": safe_tx,
}

# Forenklet illustrasjon av prinsippet. I praksis bor du bruke et vedlikeholdt
# verktoy fra sikkerhetsmiljoet, som safe-tx-hashes-util, eller Safes eget API
# for a beregne hashen helt noyaktig.
signable = encode_typed_data(full_message=typed_data)
print("Sammenlign denne hashen med det som vises i Safe og pa lommebokens skjerm:")
print(signable.body.hex())

Når du kjører skriptet, skal terminalen vise noe i denne stilen:

$ python3 verifiser_safetx.py
Sammenlign denne hashen med det som vises i Safe og pa lommebokens skjerm:
0x8f3a9c2e1b7d4f6a0c5e8b2d9f1a3c7e6b4d8f2a1c9e3b7d5f0a2c4e6b8d1f3a

Hvis denne hashen ikke matcher det Safe-grensesnittet eller lommeboken viser, skal ingen signere. Et avvik betyr enten en feil i inndataene dine eller, i verste fall, at grensesnittet du stoler på er kompromittert.

Steg 10 til 12: overvåking, sikkerhetskopi og gjenopprettingstest

Steg 10: Sett opp overvåking som varsler deg automatisk hvis noe forlater den kalde lommeboken uten at du forventet det. Dette fanger opp forsøk raskt, selv om et enkelt steg i signeringsflyten skulle svikte. Kjør overvåkingsskriptet på en helt separat maskin fra den luftgapte enheten, med kun lesetilgang til kjeden, slik at selve overvåkingen ikke introduserer en ny, uønsket tilkobling til det luftgapte oppsettet.

from web3 import Web3
import time

RPC_URL = "https://din-ethereum-node.example"
COLD_WALLET = "0xDIN_SAFE_ADRESSE"

w3 = Web3(Web3.HTTPProvider(RPC_URL))
last_checked_block = w3.eth.block_number

def send_alert(tx_hash):
    print(f"VARSEL: Utgaende transaksjon fra kald lommebok: {tx_hash}")
    # Koble til Slack, e-post eller SMS her

while True:
    latest_block = w3.eth.block_number
    for block_num in range(last_checked_block + 1, latest_block + 1):
        block = w3.eth.get_block(block_num, full_transactions=True)
        for tx in block.transactions:
            if tx["from"].lower() == COLD_WALLET.lower():
                send_alert(tx["hash"].hex())
    last_checked_block = latest_block
    time.sleep(15)

Steg 11: Lag en offline sikkerhetskopi av konfigurasjonen, som Safe-adressen, eiernes offentlige adresser og terskelen, uten å digitalisere selve seed-frasen. Krypter filen og lagre den på minst to fysisk separate steder. Ønsker du å dele opp selve seed-frasen på en sikrere måte enn en enkelt papirkopi, kan du se på SLIP-39 Shamir Backup for seed-fraser som et alternativ.

# Krypter en offline sikkerhetskopi av konfigurasjonen, ikke selve seed-frasen
gpg --symmetric --cipher-algo AES256 --output safe-config-backup.gpg safe-config.json

# Lagre den krypterte filen pa minst to fysisk separate steder
cp safe-config-backup.gpg /media/ekstern-disk-1/
cp safe-config-backup.gpg /media/ekstern-disk-2/

Steg 12: Test hele gjenopprettingsprosedyren før du flytter hovedbeløpet inn, og gjenta testen minst årlig. Gjenopprett seed-frasen på et separat, faktisk luftgapt apparat, bekreft at samme adresse dukker opp, og bekreft at samme derivasjonssti brukes. Dette er steget flest hopper over, og det er samtidig det som avgjør om katastrofeplanen din faktisk fungerer den dagen du trenger den.

Komplett eksempelprosjekt: verifiser Safe-transaksjoner offline

Sett sammen blir stegene ovenfor til et lite, komplett verktøy du kan bruke hver gang du signerer noe fra den kalde lommeboken. Mappestrukturen er enkel med vilje, slik at du kan kjøre den fra en offline maskin uten avhengigheter du ikke kontrollerer selv.

verifiser_safetx.py: beregner EIP-712-hashen for transaksjonen basert på rådata du taster inn manuelt eller limer inn fra QR-innholdet
overvak_lommebok.py: web3.py-skriptet fra steg 10, kjørt på en separat, tilkoblet maskin som kun har lesetilgang
backup.sh: krypterer og kopierer konfigurasjonsfilen fra steg 11 til to eksterne disker
safe-config.json: Safe-adresse, eierliste og terskel, uten seed-fraser eller private nøkler

Slik utvider du skriptet

Når grunnoppsettet fungerer, kan du legge til en fil som holder oversikt over godkjente mottakeradresser, og som lar overvåkingsskriptet flagge enhver utgående transaksjon til en adresse som ikke står på listen. Kombinert med en fast rutine der alle signerere alltid kjører verifiseringsskriptet før de signerer, dekker du både angrepet Bybit ble utsatt for og de mer ordinære feilene som phishing og skrivefeil i adresser fører til.

Lagre hele prosjektet i et versjonskontrollert repositorium på en maskin som ikke er den luftgapte enheten selv, slik at flere signerere i et team kan bruke nøyaktig samme verktøy og samme sjekkliste. Skriv en kort README-fil som forklarer rekkefølgen: hent rådata fra Safe, kjør verifiseringsskriptet, sammenlign hashen med skjermen på lommeboken, og signer først når alle tre stemmer. Denne enkle rutinen er selve kjernen i alt denne artikkelen forsøker å bygge opp til.

6 vanlige feil som ødelegger kald lagring på Ethereum

Å tro at “kald lagring” alene stopper alle angrep. Bybit-hacket viste at signering fortsatt kan kapres via et kompromittert grensesnitt, selv når nøklene aldri har vært tilkoblet internett.
Å stole blindt på det enheten viser uten å lese feltene. Hvis skjermen bare viser en hash uten å tolke kontrakten, godkjenner du i praksis en svart boks.
Å bruke samme “offline” datamaskin til å generere QR-koder og surfe på nett ved en annen anledning. Luftgapet forsvinner i det øyeblikket maskinen kobles til internett en eneste gang.
Å samle alle signererne hos samme leverandør med identisk firmware. En sårbarhet i én produsents programvare eller frontend kan da kompromittere hele kvorumet samtidig.
Å aldri teste gjenoppretting før pengene flyttes inn. Mange oppdager først under en reell krise at derivasjonsveien var skrevet ned feil.
Å lagre seed-frasen digitalt “for sikkerhets skyld”. Et bilde, en tekstfil eller en passordbeskyttet notatapp knytter den luftgapte hemmeligheten til en enhet med internettforbindelse, og fjerner poenget med å ha kjøpt en luftgapt lommebok i utgangspunktet.

Feilsøking: 8 vanlige problemer og hvordan du løser dem

De fleste problemene du møter underveis handler om inkompatible standarder eller mangelfull verifisering, ikke om at maskinvaren i seg selv er defekt. Gå gjennom tabellen under før du kontakter produsentens support, siden mange av disse problemene løses på et par minutter uten å måtte sende enheten til service.

Problem	Sannsynlig årsak	Løsning
QR-koden skannes ikke	For høy datamengde i én kode, lav skjermlysstyrke, eller feil UR-versjon	Øk lysstyrken, hold telefonen nærmere, bekreft at begge sider bruker samme BC-UR/ERC-4527-standard
Transaksjonshashen stemmer ikke med det du forventet	Frontend kan være manipulert, eller feil kjede er valgt	Beregn hashen offline med skriptet fra steg 9, og bytt Safe-klient hvis avviket vedvarer
Firmwareverifisering mislykkes	Korrupt nedlasting, feil offentlig nøkkel, eller manipulert fil	Last ned firmwaren på nytt direkte fra produsentens offisielle side og verifiser PGP-signaturen igjen
Enheten fryser etter QR-skanning	For stor datamengde for enhetens minne, eller skadet minnekort	Del transaksjonen i mindre deler der det er mulig, formater minnekortet, oppdater firmware
Multisig-terskelen nås ikke	Signaturer knyttet til feil derivasjonssti eller feil Safe-versjon	Bekreft at alle signererne bruker samme derivasjonssti og samme kontraktsversjon i Safe
Beløpet i nettleseren avviker fra beløpet på enheten	Kompromittert frontend eller ondsinnet nettleserutvidelse	Stopp signeringen umiddelbart, verifiser rådataene offline, varsle de andre signererne
Enheten pares ikke med Safe via QR	Inkompatibel UR-versjon mellom enhet og klient	Oppdater begge til nyeste stabile versjon, eller bruk mikroSD-overføring i stedet for QR
Gjenopprettingstesten gir feil adresse	Feil derivasjonssti eller feil ordliste/språk brukt ved gjenoppretting	Bekreft BIP-39-ordlisten og standard Ethereum-sti (m/44’/60’/0’/0/0) på nytt utstyr før produksjon

Hvis du fortsatt sitter fast etter å ha gått gjennom alle punktene, er det tryggere å stoppe helt og starte signeringsprosessen på nytt fra steg 6, enn å prøve å tvinge en transaksjon gjennom et oppsett du ikke lenger er sikker på fungerer riktig. En forsinket transaksjon koster deg ingenting, en feilsignert transaksjon kan koste deg alt.

Avanserte tips for team og DAO-er

Fordel leverandører i multisig-oppsettet

Hvis en organisasjon styrer en Safe med flere signerere, bør ikke alle bruke samme maskinvareprodusent og samme firmware-versjon. Spre eierskapet mellom for eksempel Keystone, Keycard og SafePal. En feil eller sårbarhet hos én produsent påvirker da bare én av signaturene, ikke hele kvorumet. Det samme prinsippet gjelder programvaren som genererer QR-kodene, bruk ikke identisk oppsett på tvers av alle signererne.

Sett også en fast rutine for å oppdatere referansen til godkjente Safe-kontraktversjoner, ettersom kontraktene selv oppgraderes over tid. Hold et øye med utviklingen rundt EIP-7702 og kontostandardisering på Ethereum, siden endringer i hvordan konti kan utføre batch-transaksjoner også endrer hva “å signere” faktisk innebærer i praksis. Bruk uavhengige verktøy fra sikkerhetsmiljøet til å dobbeltsjekke transaksjonshasher før hver signering, i tillegg til det innebygde grensesnittet i Safe, slik at ingen enkelt kilde til sannhet står ukontrollert.

Planlegg for eierskifte og nødsituasjoner

En multisig er bare så robust som planen for hva som skjer når en signerer blir utilgjengelig, enten det er fordi en ansatt slutter, en enhet blir mistet, eller noe verre skjer. Dokumenter en fast prosedyre for å bytte ut en eier i Safe, inkludert hvem som må godkjenne endringen og hvor den nye enheten skal genereres og verifiseres før den legges til. Øv på denne prosedyren på samme måte som du øver på gjenopprettingstesten i steg 12, slik at et eierskifte under press ikke blir første gang noen i teamet faktisk har gjort det i praksis.

Kald lagring vs varme lommebøker: tallene fra 2025 og 2026

Tallene fra 2025 viser hvor mye som faktisk står på spill når signeringsflyten svikter, selv i et system bygget for å være trygt. Chainalysis anslo at over 3,4 milliarder dollar i kryptovaluta ble stjålet gjennom hele 2025. TRM Labs sin 2026 Crypto Crime Report kom til 2,87 milliarder dollar fordelt på nesten 150 hack samme år, der Bybit-hacket alene utgjorde 1,46 milliarder dollar, eller 51 prosent av totalen, ifølge TRM Labs.

Kilde	Tall	Detalje
Chainalysis, 2025	Over 3,4 milliarder dollar	Totalt stjålet i kryptovaluta gjennom hele 2025
TRM Labs, 2026 Crypto Crime Report	2,87 milliarder dollar i ~150 hack	Bybit-hacket utgjorde 1,46 milliarder dollar, 51 % av totalen
TRM Labs, H1 2026	972 millioner dollar i 207 hack	Snittet per hendelse falt sammenlignet med 2025
Analyse av 81 børsangrep (MEXC)	44 % av tapt verdi	Kom fra bare 6 % av hendelsene, siden kalde lommebøker og signeringsfeil rammer hardere per hendelse enn varme lommebok-kompromitteringer

Det mest interessante tallet er kanskje forholdet mellom antall hendelser og skadeomfang. I gjennomgangen av 81 børsangrep sto varme og lunkne lommebøker for 31 av hendelsene, altså det klart vanligste svikstedet, men de utgjorde bare 28 prosent av den tapte verdien. Kalde lommebøker og signeringsfeil sto for langt færre hendelser, men disse hendelsene var i snitt rundt ti ganger dyrere hver. Med andre ord: kald lagring gjøres riktig oftere enn den gjøres feil, men når den gjøres feil, er skadene enorme. Det er nettopp derfor uavhengig verifisering av hver signering betyr så mye mer i et kald lagring-oppsett enn i en vanlig lommebok.

Det er verdt å lese disse tallene med et kritisk blikk, siden ulike analysebyråer teller hendelser og tapstall noe forskjellig, og fordi ett enkelt gigantisk hack som Bybit kan dra hele årssummen kraftig opp. Uansett hvilken kilde man bruker, peker de samme dataene i samme retning: signeringsflyten, ikke selve lagringsmediet, er der de dyreste feilene skjer. Det bekrefter at pengene og tiden du legger i stegene i denne artikkelen, spesielt uavhengig verifisering i steg 9 og overvåking i steg 10, er investert i nøyaktig det svikstedet som historisk har kostet mest når det først går galt.

Hva bransjen gjør for å fjerne blindsignering for godt

Etter Bybit-hacket samlet flere store aktører seg om å løse problemet på tvers av bransjen, ikke bare i enkeltprodukter. Ethereum Foundations Trillion Dollar Security Initiative har jobbet med lommebokutviklere og sikkerhetsfirmaer om en åpen standard for hvordan strukturerte data skal tolkes og vises for brukeren, uavhengig av hvilken enhet eller app som brukes. Målet er at et kall som endrer eierlisten i en multisig-kontrakt, eller som utfører en delegatecall, alltid vises tydelig, uansett hvilken maskinvarelommebok du har i hånden.

Samtidig har åpen kildekode-prosjekter i sikkerhetsmiljøet, som verktøyene for uavhengig verifisering av Safe-transaksjonshasher nevnt tidligere i denne artikkelen, blitt en de facto-standard for team som forvalter store beløp. Safe selv har også økt fokuset på å forklare risikoen ved delegatecall-transaksjoner direkte i eget grensesnitt. OpenZeppelin pekte i sin gjennomgang av 2025 på at infrastrukturangrep, som kompromitterte private nøkler, seed-fraser og priviligert tilgang, sto for en betydelig andel av tapene i året som gikk, ifølge deres 2025-oppsummering. Konklusjonen fra hele bransjen peker samme vei: verktøyene blir bedre, men den enkelte bruker eller organisasjon må fortsatt bygge inn egen verifisering frem til standardene er fullt utbredt.

Ofte stilte spørsmål

Hva er blindsignering, og hvorfor er det farlig?

Blindsignering betyr at en maskinvarelommebok signerer en transaksjon uten å vise deg hva den faktisk gjør, bare en hash eller lite forklarende data. Det er farlig fordi du i praksis godkjenner noe du ikke kan lese, slik signererne i Bybit-hacket gjorde uten å vite det.

Er en maskinvarelommebok alene nok til å beskytte Ethereum-beholdningen min?

Nei. En maskinvarelommebok fjerner risikoen ved at private nøkler ligger på en internett-tilkoblet enhet, men den løser ikke problemet med at grensesnittet du signerer gjennom kan være manipulert. Kombiner den derfor alltid med uavhengig verifisering av transaksjonsdataene, som vist i steg 9.

Hvor mye kostet Bybit-hacket, og hva gikk galt?

Rundt 1,4 til 1,5 milliarder dollar i Ethereum, tilsvarende 401.347 ETH, ble stjålet fra en kald lommebok i februar 2025. Årsaken var en kompromittert frontend hos Safe som viste en falsk transaksjon til signererne, kombinert med at maskinvarelommeboken ikke tolket eller viste den underliggende delegatecall-instruksen.

Må jeg bruke multisig for Ethereum kald lagring?

For enkeltpersoner med moderate beløp kan en enkelt luftgapt lommebok være tilstrekkelig, forutsatt god sikkerhetskopiering. For større beholdninger, felles familiemidler eller organisasjoner er multisig via Safe å foretrekke, siden det fjerner risikoen for at én kompromittert enhet eller person kan tømme hele beholdningen alene.

Hvilken luftgapt lommebok bør jeg velge?

Velg en enhet som er eksplisitt bygget for Ethereum og EVM-kompatible kjeder, ikke en Bitcoin-fokusert enhet med begrenset Ethereum-støtte. Keystone 3 Pro, Keycard Shell og SafePal S1 Pro er blant modellene som støtter QR-basert luftgapt signering for Safe-transaksjoner per i dag.

Hvordan tester jeg at gjenopprettingen faktisk fungerer?

Gjenopprett seed-frasen på et separat luftgapt apparat og bekreft at samme adresse dukker opp, med samme derivasjonssti. Gjør dette før du flytter hovedbeløpet inn, og gjenta testen minst en gang i året for å fange opp eventuelle feil i notatene dine tidlig.

Er clear signing løsningen på blindsignering?

Clear signing er et stort skritt i riktig retning, fordi det lar enheten din tolke og vise strukturerte data i klartekst. Det fjerner likevel ikke behovet for uavhengig verifisering, siden standarden fortsatt er under utrulling og ikke alle enheter og kontraktstyper er dekket ennå.

Hva gjør jeg hvis QR-koden ikke skanner?

Øk lysstyrken på skjermen som viser koden, hold enhetens kamera nærmere, og bekreft at både Safe-klienten og maskinvarelommeboken bruker samme versjon av BC-UR/ERC-4527-standarden. Hvis problemet fortsetter, prøv en overføring via mikroSD-kort i stedet, hvis enheten din støtter det.

Kan jeg bruke det samme oppsettet for andre ERC-20-tokens enn ETH?

Ja. Safe og de luftgapte lommebøkene i denne artikkelen fungerer på samme måte for ERC-20-tokens som for ren ETH, siden alle transaksjoner på Ethereum bruker samme underliggende signeringsmekanisme. Kontrollér likevel alltid kontraktadressen til selve tokenet før du signerer en overføring, siden en forfalsket kontraktadresse er en helt egen risiko som ingen luftgap eller multisig beskytter deg mot.

Ethereum Kald Lagring Uten Blindsignering: 12 Steg [2026]