MPC-Lommebok: Oppsett uten Seed-Frase i 12 Steg

En stjålet 24-ords seed-frase har vært den vanligste enkeltårsaken til tapte kryptomidler de siste ti årene. Et bilde av en lapp, en phishing-side som ber om «gjenoppretting», eller en skadelig app som leser utklippstavlen er alt som skal til. MPC-lommebøker (multi-party computation) prøver å fjerne dette enkeltpunktet for svikt ved aldri å samle hele den private nøkkelen på ett sted. I 2026 bruker leverandører som Zengo, Fireblocks og Coinbase denne teknologien til både privatpersoner og institusjoner, og terskelsignaturer dukker opp i stadig flere lommebok-apper som en erstatning for den klassiske seed-frasen.

Denne guiden tar deg gjennom hele prosessen: fra å forstå hva terskelsignaturer egentlig er, via et komplett oppsett av en MPC-lommebok med testoverføring og gjenopprettingstest, til en liten kodedemo som viser matematikken bak et nøkkeldelt oppsett. Du får også en oversikt over de vanligste fallgruvene, en feilsøkingsliste for de problemene som faktisk dukker opp i praksis, og en gjennomgang av hva Bybit-hacket i februar 2025 og en kjent svakhet i GG18/GG20-implementasjoner faktisk lærte bransjen.

Google · Foretrukne kilder

Gå ikke glipp av nye tech-saker på Google

Legg til Shattered én gang i Google-appen, så dukker artiklene våre opp i forslagene dine.

Legg til nå

Hva er en MPC-lommebok, og hvorfor dukker den opp nå

En MPC-lommebok (Multi-Party Computation) bygger på et prinsipp hvor den private nøkkelen aldri eksisterer som ett komplett objekt. I stedet deles den opp i kryptografiske «shares» som ligger på separate enheter, servere eller hos separate parter. Når du skal signere en transaksjon, beregner de aktuelle partene signaturen sammen uten at noen av dem på noe tidspunkt rekonstruerer hele nøkkelen. Resultatet er en helt vanlig signatur som blokkjeden ikke kan skille fra en signatur fra en tradisjonell lommebok, ifølge en gjennomgang fra Bitcoin Foundation om hvordan MPC flytter krypto bort fra seed-frasen som eneste sikkerhetsmekanisme.

Den mest synlige forskjellen for en vanlig bruker er at mange MPC-lommebøker ikke genererer en tradisjonell 12- eller 24-ords gjenopprettingsfrase. I en klassisk HD-lommebok (hierarkisk deterministisk) kan den ene seed-frasen gjenskape samtlige avledede kontoer hvor som helst. Det gjør frasen enormt praktisk, men også enormt sårbar: den som får tak i ordene, får tak i alt. MPC fjerner nettopp dette enkeltpunktet, fordi ingen enkelt «share» alene kan godkjenne en transaksjon.

Zengo er et av de mest kjente eksemplene for privatpersoner. I deres modell ligger én nøkkeldel på brukerens egen telefon, og én ligger hos Zengos infrastruktur. Verken telefonen eller serveren kan alene godkjenne en overføring, noe som er selve poenget med oppsettet, forklares det i en gjennomgang fra Cypherock om hvordan maskinvarelommebøker nå også dropper seed-frasen. Fireblocks har bygget en tilsvarende, men mer institusjonstung løsning, med distribuert nøkkelhåndtering og en policy-motor som styrer hvem som kan godkjenne hvilke transaksjoner. Coinbase har også egen MPC-infrastruktur, primært rettet mot utviklere som vil bygge innebygde lommebøker uten å tvinge sluttbrukeren til å håndtere en seed-frase manuelt.

Det som gjør utviklingen interessant akkurat nå, er at de tre store eksemplene (Zengo, Fireblocks og Coinbase) dekker tre helt forskjellige deler av markedet samtidig. Zengo retter seg mot vanlige forbrukere som vil slippe å tenke på en papirlapp. Fireblocks retter seg mot børser, fond og bedrifter som må dokumentere hvem som godkjente hva og når. Coinbase retter seg mot utviklere som bygger apper der sluttbrukeren ideelt sett ikke skal merke at det ligger en lommebok under overflaten i det hele tatt. Det er tre ulike produktkategorier, men de deler den samme underliggende kryptografiske idéen, og det er nettopp denne gjenbrukbarheten som har gjort MPC til et mer sentralt verktøy i 2026 enn det var for bare noen år tilbake.

Interessen handler ikke bare om komfort. Flere analyser i 2026 peker på en serie hendelser der tradisjonelle multisig-oppsett og eksponerte adminnøkler har blitt utnyttet gjennom sosial manipulering snarere enn gjennom svak kryptografi, deriblant angrepet mot Drift i april 2026 og det langt større Bybit-angrepet i februar 2025. MPC blir derfor løftet frem som et verktøy for å redusere nettopp den typen angrepsflate, selv om det ikke løser alt, et poeng vi kommer tilbake til senere i artikkelen.

MPC mot maskinvarelommebok og seed-frase: den store forskjellen

Det er lett å tro at MPC bare er «enda en type lommebok», men de tre modellene løser sikkerhet på fundamentalt forskjellige måter. En maskinvarelommebok som Ledger eller Trezor genererer en seed-frase inne i en sikker element-brikke, og nøkkelen forlater aldri enheten under signering. Risikoen flyttes dermed til backupen: taper du eller blir frastjålet de 24 ordene, er alt tapt uansett hvor enheten fysisk befinner seg, påpekes det i en sammenligning fra Kairo Guard.

En ren seed-frase-lommebok uten maskinvare er den enkleste, men også mest utsatte modellen. Nøkkelen ligger på en enhet med internettforbindelse, og frasen er den eneste gjenopprettingsmekanismen som finnes. Et skjermbilde, en skadevare-infeksjon eller et øyeblikks uoppmerksomhet rundt phishing er nok til at hele saldoen forsvinner.

MPC flytter problemet et annet sted. Fordi nøkkelen aldri eksisterer samlet, kan tap av én enkelt share i prinsippet ikke tømme lommeboken alene. Men dette skaper en ny type avhengighet: du er nå avhengig av at leverandørens infrastruktur, autentiseringssystem og eventuelle sosiale gjenopprettingsmekanisme faktisk er tilgjengelig når du trenger den. Tabellen under oppsummerer forskjellene slik de beskrives i flere uavhengige 2026-sammenligninger.

Egenskap	Seed-frase-lommebok	Maskinvarelommebok	MPC-lommebok
Hvor nøkkelen ligger	Samlet, på enheten	Samlet, i sikker brikke	Delt i shares, flere steder
Gjenoppretting	12/24-ords frase	12/24-ords frase	Oftest ingen klassisk frase
Enkeltpunkt for svikt	Frasen	Frasen (backup)	Tilgang til nok shares
Signeringssted	Åpent på enheten	Inne i sikker brikke	Beregnet i fellesskap, ingen full nøkkel samlet
Avhengighet av leverandør	Lav	Lav etter kjøp	Middels til høy
Vanligste angrepsvektor	Phishing av frasen	Fysisk tilgang/firmware	Kompromittert klient eller policy-godkjenning

Konklusjonen fra disse sammenligningene er konsekvent: MPC er sterkere mot tap eller phishing av én enkelt hemmelighet, mens maskinvarelommebøker fortsatt er sterkere mot fjernkompromittering av selve signeringsmiljøet. Hvilken modell som er «tryggest» avhenger av hvilken trusselmodell du faktisk står mot, ikke av et absolutt sikkerhetshierarki.

Terskelsignaturer forklart: ECDSA, EdDSA og hvorfor ingen har hele nøkkelen

Det tekniske hjertet i en MPC-lommebok er det som kalles en terskelsignatur (threshold signature). I stedet for å dele en eksisterende nøkkel inn i stykker og lime den sammen igjen for å signere, lar protokoller som GG18 og GG20 flere parter beregne en gyldig signatur for én felles offentlig nøkkel, uten at noen av partene på noe tidspunkt har tilgang til den fullstendige private nøkkelen, forklares det i en teknisk gjennomgang fra Proof of Talk om MPC, multisig og HSM-er.

Dette er en viktig teknisk nyanse som ofte forveksles med multisig. Et vanlig multisig-oppsett krever flere separate, synlige signaturer på blokkjeden, og hver signatur kan knyttes til en egen offentlig nøkkel. En terskelsignatur produserer derimot én enkelt, helt ordinær signatur som ser identisk ut med en signatur fra en vanlig lommebok. Blokkjeden vet ikke, og bryr seg ikke om, at signaturen egentlig ble fremforhandlet av flere parter bak kulissene.

For ECDSA-baserte kjeder som Bitcoin og Ethereum er GG18 og GG20 de mest brukte protokollfamiliene for dette. For kjeder som bruker EdDSA (Ed25519-signaturer), finnes tilsvarende terskelprotokoller, men den underliggende matematikken er annerledes fordi ECDSA og EdDSA signerer på forskjellige måter. Nyere skjemaer som FROST har også begynt å ta over for eldre ECDSA-terskelprotokoller i noen produkter, fordi de håndterer et bredere spekter av terskler (for eksempel 3-av-5 eller 7-av-10) mer effektivt.

Skjema	Signaturtype	Typisk brukstilfelle	Kjent svakhet/merknad
GG18	Terskel-ECDSA	Bitcoin, Ethereum, institusjonelle lommebøker	Sårbar ved mangelfull validering av Paillier-nøkler (CVE-2023-33241)
GG20	Terskel-ECDSA	Oppfølger til GG18, raskere rundeantall	Samme klasse implementasjonsrisiko som GG18 hvis uendret
Terskel-EdDSA	Ed25519-basert	Solana og andre EdDSA-kjeder	Annen matematikk enn ECDSA, krever egen implementasjon
FROST	Terskel-Schnorr/EdDSA	Nyere lommebøker, flexible terskler	Yngre i produksjon, færre års feltobservasjon

Det siste punktet i tabellen er verdt å dvele ved. I 2023 ble det avdekket at flere produksjonsimplementasjoner av GG18/GG20 ikke validerte motpartenes Paillier-offentlige nøkler godt nok. Det åpnet en teoretisk vei til nøkkelutlekking, og Fireblocks rapporterte at utnyttelse i verste fall kunne skje etter så få som 16 signaturer i det beskrevne scenarioet. Dette er ikke et bevis på at MPC som konsept er svakt, men et konkret eksempel på at sikkerheten i MPC avhenger like mye av implementasjonskvalitet som av selve den kryptografiske ideen.

Forskjellen mellom GG18 og GG20 handler i hovedsak om effektivitet, ikke om det grunnleggende sikkerhetsnivået. GG18 krever flere kommunikasjonsrunder mellom partene for å ferdigstille en signatur, mens GG20 er bygget for å redusere antallet runder og dermed gjøre signeringen raskere i praksis, noe som betyr mindre ventetid når flere parter må samhandle over nettverk med varierende forsinkelse. For terskel-EdDSA er bildet litt annerledes: fordi Ed25519 bruker et deterministisk signeringsskjema der nonce-verdien avledes direkte fra meldingen og nøkkelen i stedet for å genereres tilfeldig for hver signatur, krever en distribuert EdDSA-implementasjon egne mekanismer for å sikre at alle parter kommer til samme nonce uten å avsløre sin egen del av hemmeligheten til de andre. Det er en av grunnene til at terskel-EdDSA har tatt lengre tid å få inn i produksjonsklare produkter enn terskel-ECDSA.

Forutsetninger før du setter opp en MPC-lommebok

Du trenger ikke være utvikler for å sette opp en konsument-MPC-lommebok, men hele guiden under forutsetter noen konkrete ting. Hvis du også vil kjøre den lokale kodedemoen senere i artikkelen for å forstå matematikken bak terskelsignaturer, trenger du i tillegg et par verktøy til.

Behov	Minimumskrav	Merknad
Smarttelefon	iOS 17 eller nyere / Android 13 eller nyere	For MPC-appens enhetsdel og biometrisk lås
E-postkonto	Med tofaktorautentisering aktivert	Brukes ofte som del av gjenopprettingskjeden
MPC-lommebokapp	Nyeste versjon fra offisiell app-butikk	Eksempel: Zengo, eller institusjonell løsning som Fireblocks
Liten testbeholdning	Et beløp du tåler å tape	Brukes til funksjonstest før du flytter reelle midler
Python	3.11 eller nyere	Kun for den lokale terskelsignatur-demoen
Node.js	20 LTS eller nyere	Alternativ til Python for demoen, valgfritt

Legg spesielt merke til testbeholdningen. Hele poenget med fremgangsmåten i denne artikkelen er at du aldri flytter reelle, betydelige midler inn i et oppsett du ikke selv har testet gjenopprettingen på. Det er den ene regelen som går igjen i nesten alle sikkerhetsanalyser av MPC-lommebøker i 2026, og den koster deg ingenting å følge.

Steg 1-3: Velg leverandør, terskelmodell og last ned appen trygt

Steg 1: Definer trusselmodellen din før du velger leverandør. En privatperson som bare vil unngå å tape krypto til phishing har et helt annet behov enn en DAO-kasse eller en bedrift som flytter store summer daglig. Analyser fra 2026 deler typisk brukere inn i fire grupper: enkeltperson, aktiv trader, familie/arv, og organisasjon/bedrift. Hver gruppe bør vekte MPC, maskinvare og multisig forskjellig, noe vi går mer i detalj på i avsnittet om anbefalinger etter brukertype.

Steg 2: Velg terskelmodell. For privat bruk er en 2-av-2-modell (telefon + leverandørens server) den vanligste, slik Zengo bruker den. For organisasjoner er en 2-av-3 eller 3-av-5 modell mer vanlig, slik at ingen enkeltperson og ingen enkelt server kan signere alene. Flere shares gir høyere sikkerhet mot tap av en enkelt node, men gjør også den daglige signeringsprosessen tregere og mer avhengig av at flere parter er tilgjengelige samtidig.

Steg 3: Last ned appen fra offisiell kilde og verifiser integriteten. Last alltid ned direkte fra App Store, Google Play, eller leverandørens offisielle nedlastingsside, aldri fra en lenke i en e-post eller et søkeresultat med annonsemerking. Hvis leverandøren publiserer en sjekksum for installasjonsfilen (vanligst for institusjonelle klienter som lastes ned som binærfil), bør du verifisere den før installasjon:

# Last ned installasjonsfilen og den offisielt publiserte sjekksummen
sha256sum mpc-client-installer.bin

# Eksempel på resultat:
# 7f9c3a1e2d4b8f6a0c5e9d2b7a4f1e8c3d6a9b2e5f8c1a4d7b0e3f6a9c2d5b8e  mpc-client-installer.bin

# Sammenlign med sjekksummen som er publisert på leverandørens offisielle side.
# Stemmer de to verdiene IKKE, avbryt installasjonen og kontakt leverandørens support.

Dette enkle trinnet fanger opp manipulerte installasjonsfiler som er blitt distribuert via falske nedlastingssider, en angrepsvektor som har økt i takt med at MPC-klienter har blitt mer populære.

Steg 4-6: Generer shares og sikre enhetsdelen

Steg 4: Opprett lommeboken og generer nøkkeldelene. Når du åpner appen for første gang, vil den normalt generere sin del av nøkkelen lokalt på enheten, samtidig som den kommuniserer med leverandørens server for å generere den tilsvarende serverdelen. Ingen av partene overfører sin halvdel til den andre. I stedet kjøres en distribuert nøkkelgenereringsprotokoll (DKG) som sikrer at begge parter ender opp med en matematisk korrekt share uten at noen av dem ser den andres hemmelighet.

Steg 5: Lås enhetsdelen med biometri og lang PIN. Enhetsdelen av nøkkelen ligger normalt kryptert i telefonens sikre lagringsområde. Aktiver biometrisk lås (Face ID, fingeravtrykk) og sett en PIN med minst 6 siffer som ikke er gjenbrukt fra andre kontoer. Dette hindrer at noen som får fysisk tilgang til en ulåst telefon, umiddelbart kan godkjenne transaksjoner.

Steg 6: Konfigurer sky- eller serverdelen og gjenopprettingskjeden. For en privatperson betyr dette typisk å knytte kontoen til e-postadressen med tofaktorautentisering, og eventuelt legge til et sosialt gjenopprettingsalternativ (en betrodd kontakt som kan bekrefte identiteten din hvis telefonen går tapt). For en institusjonell løsning betyr dette å sette opp policy-motoren som definerer hvem som må godkjenne hvilke typer transaksjoner, noe vi går gjennom i detalj i steg 10.

Steg 7-9: Test gjenoppretting, finansier og verifiser på kjeden

Steg 7: Test gjenoppretting FØR du setter inn reelle midler. Dette er det enkelttrinnet flest brukere hopper over, og det enkelttrinnet som oftest nevnes i sikkerhetsgjennomganger av seedless-lommebøker fra 2026. Logg ut, installer appen på nytt (eller bruk leverandørens dedikerte gjenopprettingsflyt), og bekreft at du faktisk kommer tilbake inn i lommeboken med din opprinnelige saldo synlig, uten å måtte kontakte support. Hvis gjenopprettingen feiler her, er det langt bedre å oppdage det nå enn etter at du har flyttet hele porteføljen din inn.

Steg 8: Finansier med et lite testbeløp. Overfør et beløp du tåler å tape fullstendig, ikke et beløp du «egentlig ikke bryr deg om», men et faktisk ubetydelig beløp. Vent til overføringen er bekreftet med minst én blokk før du går videre.

Steg 9: Verifiser transaksjonen og signaturen uavhengig. Bruk en offentlig blokkutforsker-API for å bekrefte at midlene faktisk har landet på den adressen lommeboken viser deg, i stedet for å bare stole på appens eget skjermbilde:

# Eksempel: sjekk saldo på en Bitcoin-adresse via en offentlig blokkutforsker-API
curl -s "https://blockchain.info/rawaddr/DIN_ADRESSE_HER" | python3 -m json.tool

# Eksempel på utdrag fra svaret:
# {
#   "address": "DIN_ADRESSE_HER",
#   "n_tx": 1,
#   "total_received": 50000,
#   "final_balance": 50000
# }
# Beløpet er angitt i satoshi (1 BTC = 100 000 000 satoshi).
# Stemmer final_balance med det appen viser, er signeringen og kringkastingen bekreftet uavhengig.

Denne kontrollen er spesielt viktig fordi den avdekker en helt annen klasse feil enn kryptografien: en app-klient med en bug, eller i verste fall en kompromittert klient, kan vise feil saldo eller feil mottakeradresse i brukergrensesnittet selv om selve signeringen var korrekt. En uavhengig kilde beskytter deg mot nettopp det scenarioet, det samme scenarioet som gjorde Bybit-hacket mulig, der godkjennerne så riktig informasjon i grensesnittet men signerte en helt annen transaksjon under overflaten.

Steg 10-12: Policyer, overvåking og rotasjon av shares

Steg 10: Sett opp transaksjonspolicy (mest relevant for team og bedrifter). En policy-motor lar deg definere regler som «alle overføringer over 10 000 USD krever to godkjennere» eller «ingen overføringer til nye adresser uten en 24-timers tidslås». Et forenklet eksempel på hvordan en slik regel kan se ut i et policy-dokument:

{
  "policy_rules": [
    {
      "rule_id": "high-value-transfer",
      "condition": { "amount_usd_gte": 10000 },
      "required_approvers": 2,
      "approver_group": "treasury-signers"
    },
    {
      "rule_id": "new-address-delay",
      "condition": { "destination_is_new_address": true },
      "action": "delay",
      "delay_hours": 24
    },
    {
      "rule_id": "block-blacklisted-destination",
      "condition": { "destination_in_blacklist": true },
      "action": "reject"
    }
  ]
}

Legg merke til at policy-motoren ikke erstatter terskelsignaturen, den kommer i tillegg til den. Terskelsignaturen sikrer at nøkkelen aldri samles, mens policyen sikrer at selv gyldige, korrekt signerte transaksjoner følger organisasjonens regler før de faktisk kringkastes.

Steg 11: Sett opp overvåking og varsling. De fleste MPC-leverandører på institusjonsnivå tilbyr varsling via e-post, Slack eller webhook ved uvanlig aktivitet, nye enheter som kobler seg til, eller mislykkede signeringsforsøk. Aktiver alt som finnes, og test at varslingen faktisk kommer frem ved å trigge en falsk hendelse (for eksempel ved å skrive feil PIN tre ganger på en testbruker).

Steg 12: Roter shares periodisk, spesielt etter enhetsbytte. Hvis en enhet som har en nøkkeldel blir mistet, stjålet, solgt eller byttet ut, må den aktuelle shareen roteres (regenereres) slik at den gamle, potensielt eksponerte delen ikke lenger er gyldig. De fleste seriøse MPC-leverandører har en innebygd funksjon for dette, ofte kalt «key refresh» eller «share rotation», og den bør kjøres umiddelbart ved enhetsbytte, ikke «en gang senere».

Bonus-steg: Bygg din egen terskelsignatur-demo lokalt

Hvis du vil forstå matematikken bak nøkkeldeling bedre enn det en app-grensesnitt kan vise deg, kan du bygge en enkel, lokal demonstrasjon av Shamir-hemmelighetsdeling, prinsippet som ligger til grunn for hvordan en hemmelighet kan deles i flere biter uten at noen enkelt bit avslører noe. Dette er en pedagogisk demo med kun standardbiblioteket i Python, ikke en produksjonsklar MPC-implementasjon, og den skal aldri brukes med ekte private nøkler eller reelle midler.

# shamir_demo.py - pedagogisk demo av 2-av-3 hemmelighetsdeling
# Kun til læring. IKKE bruk dette til å beskytte ekte private nøkler.

import secrets

PRIME = 2**127 - 1  # Stort primtall for modulær aritmetikk

def split_secret(secret, threshold=2, shares_total=3):
    coeffs = [secret] + [secrets.randbelow(PRIME) for _ in range(threshold - 1)]
    shares = []
    for x in range(1, shares_total + 1):
        y = sum(c * (x ** i) for i, c in enumerate(coeffs)) % PRIME
        shares.append((x, y))
    return shares

def reconstruct_secret(shares):
    secret = 0
    for i, (xi, yi) in enumerate(shares):
        num, den = 1, 1
        for j, (xj, _) in enumerate(shares):
            if i != j:
                num = (num * -xj) % PRIME
                den = (den * (xi - xj)) % PRIME
        secret = (secret + yi * num * pow(den, -1, PRIME)) % PRIME
    return secret

if __name__ == "__main__":
    hemmelighet = 123456789
    shares = split_secret(hemmelighet, threshold=2, shares_total=3)
    print("Genererte shares:", shares)
    rekonstruert = reconstruct_secret(shares[:2])
    print("Rekonstruert med 2 av 3 shares:", rekonstruert)

Når du kjører skriptet, får du et resultat som ligner på dette:

$ python3 shamir_demo.py
Genererte shares: [(1, 94817362...), (2, 58213904...), (3, 21610447...)]
Rekonstruert med 2 av 3 shares: 123456789

Legg merke til at ingen enkelt share (verdien ved x=1, 2 eller 3) i seg selv avslører hemmeligheten 123456789. Først når to av de tre shareene kombineres gjennom Lagrange-interpolasjon, kommer det opprinnelige tallet tilbake. Dette er selve kjerneideen i MPC: en ekte terskelsignaturprotokoll som GG20 bruker langt mer avansert matematikk (inkludert Paillier-kryptering og zero-knowledge-bevis) for faktisk å signere uten å rekonstruere hemmeligheten i det hele tatt, selv midlertidig, men prinsippet om at «ingen enkelt del avslører noe» er nøyaktig det samme.

MPC for utviklere: embedded wallets uten synlig seed-frase

Mye av veksten i MPC de siste årene har kommet fra et sted de fleste privatbrukere aldri ser: innebygde lommebøker (embedded wallets) i apper og spill. Her er ikke målgruppen en person som aktivt velger «MPC» i et menyvalg, det er en utvikler som vil la brukere eie krypto uten å måtte forklare hva en seed-frase er i det hele tatt. Coinbase sin MPC-infrastruktur er bygget nettopp for dette formålet, med API-er som lar en app generere en lommebok for en ny bruker i bakgrunnen, splitte nøkkelen i shares automatisk, og håndtere gjenoppretting gjennom appens eget innloggingssystem i stedet for en synlig 24-ords frase.

Dette skaper en litt annen risikoprofil enn forbrukerappen du laster ned selv. Når MPC-logikken er pakket inn i en tredjepartsapp, er du som bruker avhengig av at utvikleren har implementert nøkkeldelingen korrekt, at appens egen innloggingssikkerhet (ofte e-post eller sosial innlogging) er robust, og at utvikleren faktisk har forstått forskjellen mellom å bruke en MPC-leverandørs SDK riktig og å bruke den på en måte som uforvarende gjenoppretter sentralisering et annet sted i systemet, for eksempel ved å mellomlagre begge shareene på samme backend-server av praktiske årsaker under utvikling og aldri fikse det før lansering.

Hvis du selv er utvikler og vurderer å integrere en MPC-SDK i et produkt, er den viktigste sjekken å verifisere i dokumentasjonen og helst i selve nettverkstrafikken at de to (eller flere) shareene faktisk genereres og lagres separat, og at ingen enkelt komponent i din egen backend ser begge deler samtidig på noe tidspunkt. Be om en arkitekturoversikt fra leverandøren som eksplisitt viser hvor hver share ligger i hele livssyklusen, fra generering til signering til eventuell rotasjon. Hvis leverandøren ikke kan vise dette tydelig, er det et dårlig tegn, uavhengig av hvor god markedsføringen er.

Vanlige fallgruver med MPC-lommebøker

Du hopper over gjenopprettingstesten. Det er den vanligste og dyreste feilen. Test alltid gjenoppretting med et lite beløp før du flytter noe av verdi.
Du lagrer begge «sidene» av sikkerheten på samme sted. Hvis telefonens e-post-app, autentiseringsappen og MPC-klienten alle er låst med samme gjenbrukte passord, har du i praksis bygget et nytt enkeltpunkt for svikt, selv om nøkkelen formelt er delt.
Du forveksler MPC med beskyttelse mot phishing av grensesnittet. En terskelsignatur hindrer ikke at du godkjenner en transaksjon som ser riktig ut i appen, men som i realiteten sender midler et annet sted, slik tilfellet var i Bybit-hacket i februar 2025.
Du antar at leverandøren alltid er tilgjengelig. En MPC-lommebok med en sky-basert share er avhengig av at leverandørens tjeneste faktisk er oppe når du trenger å signere. Sjekk leverandørens driftshistorikk før du legger inn store summer.
Du lar klient-appen bli utdatert. Implementasjonssvakheter som den som ble funnet i flere GG18/GG20-biblioteker (CVE-2023-33241) rettes gjennom oppdateringer. En utdatert klient kan fortsatt kjøre sårbar kode måneder etter at feilen er offentlig kjent.
Du deler skjermbilder av policy-QR-koder eller gjenopprettingslenker. Disse er ofte tidsbegrenset gyldige, men i vinduet de er aktive kan de brukes av hvem som ser dem.
Du roterer aldri shares etter enhetsbytte. Selger du den gamle telefonen uten å rotere nøkkeldelen først, ligger en potensielt gjenopprettbar fragment av din sikkerhet i et apparat du ikke lenger kontrollerer.

Det som binder disse fallgruvene sammen er at ingen av dem er feil i selve MPC-matematikken. De er feil i hvordan mennesker og organisasjoner bruker et system som er designet for å fjerne ett enkeltpunkt for svikt, men som fortsatt kan få nye enkeltpunkter introdusert gjennom dårlige vaner rundt enheter, passord og rutiner. Det er derfor sjekklisten i denne artikkelen legger like mye vekt på prosess (test gjenoppretting, roter shares, overvåk aktivt) som på selve oppsettet av appen.

Feilsøking: de vanligste problemene og løsningene

De fleste problemene med MPC-lommebøker handler om kommunikasjon mellom partene som skal signere sammen, ikke om kryptografien selv. Tabellen under samler de ti vanligste symptomene brukere rapporterer, sammen med sannsynlig årsak og konkret løsning.

Symptom	Sannsynlig årsak	Løsning
Appen krasjer under opprettelse av ny share	Ustabil nettverksforbindelse under DKG-protokollen	Bytt til stabilt Wi-Fi og prøv på nytt, ikke mobildata med dårlig dekning
Gjenopprettings-e-post kommer ikke frem	E-posten havner i spam, eller filtreres av bedriftens mailserver	Sjekk spam-mappen og hvitlist leverandørens domene hos IT
Transaksjon henger i «venter på signatur»	Én av partene som trengs for terskelen er offline	Bekreft at alle nødvendige enheter/servere er tilkoblet, kontakt support hvis leverandørens node er nede
Tofaktor-koden godtas ikke under policy-godkjenning	Klokken på telefonen er ute av synk, TOTP er tidsbasert	Aktiver automatisk tidssynkronisering på enheten
Saldoen vises ikke etter overføring	Transaksjonen er ikke bekreftet i nok blokker ennå	Vent på flere bekreftelser, verifiser uavhengig via blokkutforsker
Leverandørens skytjeneste svarer ikke	Driftsavbrudd hos leverandøren	Sjekk leverandørens statusside, vent, unngå å prøve gjentatte ganger i rask rekkefølge
Du mottar et varsel om mistenkelig innlogging	Enten reelt phishingforsøk, eller ny enhet du selv la til	Bekreft identiteten på alle enheter, roter shares umiddelbart hvis uvisst
«Insufficient shares to reconstruct signature»	For få av de nødvendige partene deltok i signeringsrunden	Kontroller terskelkravet (f.eks. 2-av-3) og sørg for at nok parter er tilgjengelige
Gammel enhet mistet før rotasjon	Share ble ikke deaktivert før enheten forsvant	Roter alle gjenværende shares umiddelbart og flytt midler til nytt oppsett ved tvil
API-nøkkel for policy-motor avvist	Nøkkelen er utløpt eller feil scope er tildelt	Generer ny API-nøkkel med korrekt tillatelsesnivå i leverandørens konsoll

Et fellestrekk ved nesten alle disse symptomene er at de skyldes koordinering mellom parter, ikke korrupte data eller ødelagte nøkler. Det er en direkte konsekvens av selve designet: fordi ingen enkelt part kan signere alene, må alle nødvendige parter faktisk være tilgjengelige og enige samtidig. Det gjør MPC mer robust mot tyveri av én enkelt hemmelighet, men mer sårbar for enkle tilgjengelighetsproblemer som en glemt PIN, en utløpt sesjon, eller en telefon uten nettverksdekning i det kritiske øyeblikket. Bygg derfor rutiner for hvordan du håndterer «part utilgjengelig»-situasjoner før du står i en, ikke etterpå.

Avanserte tips for team, DAO-er og bedrifter

For organisasjoner som flytter betydelige summer, er det flere teknikker som går utover det grunnleggende oppsettet. Den første er å kombinere MPC med en hardware security module (HSM) for en av shareene, slik at minst én del av nøkkelen aldri eksisterer utenfor fysisk sikret maskinvare, selv om resten av systemet er sky-basert. Dette gir en hybridmodell som verken er ren MPC eller ren maskinvarelommebok, men tar styrker fra begge.

Den andre teknikken er å sette opp en «kanarifugl»-adresse: en liten, overvåket adresse som varsler umiddelbart ved enhver aktivitet, plassert slik at et eventuelt kompromittert policy-system eller en kompromittert signeringsklient vil treffe denne adressen før de treffer skattekisten. Det gir et tidlig varsel uten å stole på at hovedsystemet selv oppdager avviket.

Den tredje teknikken er automatisert revisjon av rotasjonsstatus. I stedet for å stole på at noen «husker» å rotere shares etter enhetsbytte, kan et enkelt script kjøre som en påminnelse koblet til personalsystemet, slik at avgang eller enhetsbytte automatisk trigger en rotasjonsoppgave:

#!/bin/bash
# share_rotation_check.sh - enkel påminnelsessjekk, kjøres ukentlig via cron
# Leser en lokal liste over enheter og flagger de som er eldre enn 90 dager

TERSKEL_DAGER=90
I_DAG=$(date +%s)

while IFS=, read -r enhetsnavn sist_rotert; do
  sist_rotert_sek=$(date -d "$sist_rotert" +%s)
  diff_dager=$(( (I_DAG - sist_rotert_sek) / 86400 ))
  if [ "$diff_dager" -gt "$TERSKEL_DAGER" ]; then
    echo "ADVARSEL: $enhetsnavn har ikke rotert share på $diff_dager dager"
  fi
done < enhetsliste.csv

Den fjerde teknikken er geografisk og organisatorisk spredning av shares. En vanlig feil i institusjonelle oppsett er at alle shareene, selv om de teknisk ligger på separate servere, driftes av det samme teamet i samme kontor, bak samme VPN, med de samme personene som har administratortilgang til alt. Det gjenoppretter i praksis et enkeltpunkt for svikt på organisasjonsnivå, selv om kryptografien i seg selv fortsatt er korrekt distribuert. Spre i stedet administrasjonen av shareene på tvers av team, geografi eller til og med juridiske enheter der det er praktisk mulig, slik at en enkelt kompromittert administrator-konto eller et enkelt kontorinnbrudd ikke gir tilgang til nok shares for å nå terskelen.

Til sist, for DAO-er og team som vurderer mellom MPC og tradisjonell multisig, er anbefalingen fra flere 2026-analyser å ikke se dette som et enten-eller-valg. En kombinasjon, der policy-motoren krever godkjenning fra både en MPC-signatur og et separat multisig-kvorum for de aller største transaksjonene, gir et lag med redundans som gjør at en enkelt kompromittert komponent, enten det er en MPC-klient eller en multisig-signer, ikke er nok til å tømme kassen alene.

Brukertype	Anbefalt primærmodell	Anbefalt tillegg
Enkeltperson, mindre beløp	MPC (2-av-2, app-basert)	Test gjenoppretting hver 6. måned
Aktiv trader	MPC med policy for daglig overføringsgrense	Separat kald lagring for langsiktig beholdning
Familie/arv	MPC eller multisig med betrodd tredjepart som en av partene	Dokumentert, testet arveplan
DAO/organisasjon	MPC (3-av-5 eller høyere) kombinert med multisig-kvorum	Policy-motor, kanarifugl-adresse, HSM for minst én share

Det komplette prosjektet: slik ser en MPC-oppsett ut i praksis

Satt sammen består et komplett, produksjonsklart MPC-oppsett av fire lag som jobber sammen. Det første laget er selve terskelsignaturprotokollen, enten GG20 for ECDSA-kjeder eller en EdDSA/FROST-variant, som sørger for at ingen enkelt part noensinne ser hele nøkkelen. Det andre laget er enhetssikkerheten, biometri, PIN og kryptert lokal lagring, som beskytter den delen av nøkkelen som faktisk ligger på din enhet. Det tredje laget er policy-motoren, som definerer forretningsreglene for hvilke transaksjoner som krever ekstra godkjenning eller forsinkelse. Det fjerde laget er overvåkingen, som varsler deg når noe av det forrige laget blir utfordret.

Den lokale Shamir-demoen fra tidligere i artikkelen illustrerer kun det første laget, og i en forenklet form uten de kryptografiske sikringene en ekte terskelsignatur-implementasjon har. Poenget med å bygge den selv er ikke å lage en egen produksjonslommebok, det er å forstå hvorfor en ekte MPC-lommebok ikke kan "lekke" nøkkelen gjennom en enkelt kompromittert part, samme prinsipp som i demoen, bare med langt strengere matematisk garanti i en ekte implementasjon.

Et realistisk sluttresultat for en privatperson ser slik ut: en Zengo- eller lignende app med enhetsdel sikret bak biometri, en testet og bekreftet gjenopprettingsvei via e-post og eventuelt en betrodd kontakt, et lite testbeløp som er bekreftet uavhengig via blokkutforsker, og en kalenderpåminnelse om å rotere share ved ethvert enhetsbytte. For en organisasjon legges policy-motoren, overvåkingsvarsling og eventuelt en HSM-komponent til over dette fundamentet.

Sikkerhetsincidenter: hva Bybit og GG18/GG20-saken lærte oss

To hendelser er verdt å forstå i detalj, fordi de illustrerer to helt forskjellige klasser av risiko som en MPC-lommebok ikke automatisk løser. Den første er Bybit-hacket fra februar 2025, der om lag 1,4 milliarder dollar i kryptoverdier forsvant. Ifølge NCC Groups analyse datert 10. mars 2025 kom skadelig JavaScript-kode inn via en kompromittert utviklermaskin, noe som fikk signererne til å godkjenne endret transaksjonsdata som byttet ut selve lommebok-implementasjonen de trodde de signerte for. Dette var teknisk sett et angrep mot en Safe-basert multisig-oppsett, ikke mot en MPC-protokoll, men lærdommen gjelder begge: en gyldig, korrekt signatur fra alle nødvendige parter beskytter ikke mot at partene ble lurt til å signere feil innhold.

Den andre hendelsen er den kjente svakheten i flere GG18/GG20-implementasjoner, dokumentert under CVE-2023-33241. Her lå problemet i selve implementasjonen av terskelsignaturprotokollen: mangelfull validering av motpartenes Paillier-offentlige nøkler kunne i verste fall gjøre det mulig å trekke ut nøkkelinformasjon etter et relativt lavt antall signeringer, rapportert av Fireblocks til så få som 16 signaturer i det beskrevne worst-case-scenarioet. Dette viser at selv et matematisk solid konsept som terskelsignaturer kan bli usikkert hvis den konkrete koden som implementerer det har feil, noe som er nøyaktig samme lærdom som gjelder for all kryptografisk programvare, uavhengig av hvor elegant det underliggende skjemaet er.

Begge sakene peker på det samme rådet: hold klientprogramvaren oppdatert, stol ikke blindt på at et grensesnitt viser riktig informasjon, og velg leverandører som er åpne om sikkerhetsrevisjoner og hendelseshistorikk. En oversikt over hvordan markedet for lommebøker har utviklet seg i 2026, inkludert hvor mange større tilbydere som nå tilbyr en seedless eller MPC-basert variant, finnes i en gjennomgang fra Coincub om de ledende kryptolommebøkene i 2026.

Ofte stilte spørsmål

Er en MPC-lommebok tryggere enn en maskinvarelommebok?
Det avhenger av trusselmodellen. MPC er sterkere mot tap eller phishing av én enkelt hemmelighet, fordi ingen enkelt share kan signere alene. Maskinvarelommebøker er sterkere mot fjernkompromittering av selve signeringsmiljøet, fordi nøkkelen aldri forlater den sikre brikken. Ingen av de to er universelt tryggest i alle scenarioer.

Trenger jeg fortsatt en backup hvis jeg bruker MPC uten seed-frase?
Ja. I stedet for én fysisk frase har du nå en gjenopprettingskjede som typisk involverer e-post, tofaktorautentisering og eventuelt en betrodd kontakt. Denne kjeden må testes på samme måte som en seed-frase bør testes, bare med andre komponenter.

Hva skjer hvis leverandøren av MPC-tjenesten går konkurs eller legger ned?
Dette er den viktigste avhengighetsrisikoen med leverandørbaserte MPC-løsninger. Seriøse leverandører tilbyr vanligvis en nød-eksport-funksjon eller en migreringsvei, men du bør undersøke dette før du legger inn betydelige summer, ikke etter. Spør eksplisitt om hva som skjer med din del av nøkkelen dersom tjenesten stenger på kort varsel, og test om mulig eksportfunksjonen med et lite beløp mens tjenesten fortsatt er i drift.

Er MPC det samme som multisig?
Nei. Multisig krever flere separate, blokkjede-synlige signaturer fra flere nøkler. MPC med terskelsignaturer produserer én enkelt, ordinær signatur som ser identisk ut med en vanlig signatur, selv om den ble beregnet i fellesskap av flere parter bak kulissene.

Kan jeg bruke MPC for Bitcoin og Ethereum samtidig?
Ja, de fleste etablerte MPC-leverandører støtter flere blokkjeder, siden selve terskelsignaturprotokollen (for eksempel terskel-ECDSA) fungerer likt uavhengig av hvilken ECDSA-basert kjede transaksjonen hører til.

Hvor ofte bør jeg rotere nøkkeldelene (shares)?
Umiddelbart ved ethvert enhetsbytte, tap, eller mistanke om kompromittering. Utover det anbefaler flere leverandører en rutinemessig rotasjon hver 6 til 12 måneder som god praksis, selv uten en konkret hendelse.

Er den lokale Shamir-demoen i denne artikkelen trygg å bruke for ekte nøkler?
Nei. Den er en pedagogisk demonstrasjon av det matematiske prinsippet bak nøkkeldeling, bygget med standardbiblioteket i Python for læring. En ekte MPC-implementasjon krever langt mer: sikker distribuert nøkkelgenerering, zero-knowledge-bevis, og beskyttelse mot en lang rekke sidekanalangrep som ikke er håndtert i en enkel demo.

Hva er den viktigste enkeltfeilen folk gjør med MPC-lommebøker?
Å flytte reelle midler inn før gjenopprettingen er testet. Dette gjelder uansett hvor god den underliggende kryptografien er, fordi en gjenopprettingskjede som ikke fungerer når du trenger den, gjør resten av sikkerhetsarkitekturen irrelevant. Den nest vanligste feilen er å behandle MPC som en universell løsning som gjør alle andre sikkerhetsvaner overflødige, i stedet for å se det som ett lag i en større strategi som fortsatt krever oppdatert programvare, god enhetshygiene og testet gjenoppretting.