Vi tror at den sikreste mobile kryptolommeboken er en som overvinner de iboende begrensningene til det mobile operativsystemet. For eksempel, på iOS, støtter ikke Apples CryptoKit secp256k1 elliptisk kurve, en standard for Bitcoin, Ethereum og mange andre blokkjeder.

Denne begrensningen begrenser utviklere fra å bruke det sikre elementet til enheter for nøkkellagring og transaksjonssignering. Som et resultat blir mobile kryptolommebøker klassifisert som hot wallets siden de både er koblet til internett og signerer transaksjoner utenfor et sikkert element ved hjelp av en programvareimplementering av de kryptografiske algoritmene.

Dette betyr at de private nøklene må være eksponert – i hvert fall under signering – i minnet til appmiljøet med sandkasse. Dette gjør dem mer utsatt for potensielle trusler enn en lommebok som bruker et sikkert element for å signere transaksjoner.

Til tross for manglende evne til å utføre signering på de sikre elementene direkte, noe som vil gi økt beskyttelse, har vi forpliktet oss til å tilby en åpen kildekode mobil kryptolommebok som prioriterer sikkerhet, åpenhet og brukerkontroll.

Vår sikkerhetsarkitektur er spesialbygd for å:

• Støtte flere blokkjeder
• Generer private nøkler med høy entropi, et mål på uforutsigbarhet som styrker sikkerheten
• Dra nytte av kamptestet kryptografi for å kryptere brukernes private nøkler på en sikker måte, og dra nytte av mobiltelefonens sikkerhetsmaskinvare og OS-sikkerhetsfunksjoner
• Tilby forbedret sikkerhet med et brukergenerert passord for avanserte brukere som ønsker et ekstra nivå av kryptering (på toppen av OS-nøkkelringbeskyttelsen for dekrypteringsnøkkelen)
• Skap et solid grunnlag for fremtidig inkorporering av nye nøkkeladministrasjonstyper, som maskinvarelommebøker og MPC-quorum-baserte systemer

Fordelen med åpen kildekode

Som et av dets grunnleggende sikkerhetsprinsipper, Kraken lommebok er gratis programvare med åpen kildekode, fordelt under MIT-lisensen. Ved å bygge en ny lommebok fra grunnen av var det viktig for oss å bidra til å fremme åpen kildekode og distribuert økosystem.

Uten åpen kildekode ville Kraken Wallet kreve en stor mengde tillit uten åpenhet. Dette vil gi kundene mindre beskyttelse; du kunne ikke verifisere, endre eller kjøre klienten selv hvis du ville. "Ikke stol på, verifiser!" er ikke bare et bransjemaksime, det er et av våre veiledende prinsipper.

Åpen kilde til programvaren vår oppfyller to grunnleggende mål vi først satte for dette produktet: verifiserbar, kontrollerbar tillitsminimering:

• Kontrollerbarhet: Evnen til å verifisere at sikkerhetsforutsetningene som presenteres i dette blogginnlegget er sanne. Hvem som helst kan se på kildekoden for å spesifikt forstå hva som gjøres og ikke gjøres i denne lommeboken. 

• Revisjon: Muligheten til å verifisere at utdataene fra sikkerhetsimplementeringen vår er korrekt og rapportere tilbake når det ikke er det. Vi har engasjert interne og eksterne team for å utføre sikkerhetsrevisjoner flere ganger før utgivelsen. Fremover kan hvem som helst revidere koden og lage en rapport om funnene deres.

Nøkkelgenerering og nøkkelimport

React Native, selv om det er et kraftig verktøy, har ikke en innebygd kryptomodul. For å navigere rundt dette brukte vi en pure-js-implementering (crypto-browserify) av NodeJS sin kryptomodul. crypto.randomBytes()-metoden – som genererer de faktiske tilfeldige bytene vi trenger under nøkkelgenerering – håndteres av reagere-innfødte-få-tilfeldige-verdier polyfill.

React-native-get-random-values ​​bruker innebygd kode for å bruke Cryptographically Secure Pseudorandom Number Generator (CSPRNG) tilgjengelig på enheten for å generere tilfeldige tall. På praktisk talt alle moderne enheter er denne tilfeldige tallgeneratoren støttet av en sikker maskinvare tilfeldig tallgenerator.

Under initialisering av lommeboken trekker vi entropi fra CSPRNG og konverterer den til et mnemonisk frø ved å bruke veletablerte npm-pakker (BIP32, BIP39).

Nøkler konverteres, lagres og presenteres for brukeren under BIP39-standarden, som tilbyr en mnemonisk metode som er enkel å sikkerhetskopiere med interoperabilitet for de fleste lommebøker i økosystemet. Importfunksjonen støtter gjenoppretting av BIP39-kompatible frø, som gir den beste interoperabiliteten i økosystemet. 

Nøkkeladministrasjon 

Kraken Wallet har to hemmelige verdier – frøet og mnemonic – og flere ikke-hemmelige (men fortsatt private) verdier som lommebokadresser, lommeboknavn og beskrivelser av transaksjoner.

Privat nøkkelmateriale (seed/mnemonic) lagres i Keychain (på iOS) og Keystore (på Android). Offentlig nøkkelmateriale og ikke-sensitive data (utvidede offentlige nøkler, adresser og beskrivelser) lagres i applikasjonens krypterte database (ved hjelp av Realm).

Det er flere sikkerhetskontroller som beskytter dataene:

• App-lås: En tilfeldig generert 64-byte streng lagret i nøkkelring eller nøkkellager. Tilgang til hemmeligheten er beskyttet med krav til brukertilstedeværelse – biometrisk autentisering eller autentisering med passord.

• Passord: Brukerlevert og ikke oppbevart på en enhet. I stedet må brukeren oppgi passordet manuelt når applikasjonen ber om det. Lommeboken avgjør om passordet er nødvendig ved å se to flagg (is_storage_encrypted og is_seed_encrypted) lagret i nøkkelring eller nøkkellager. Argon2-algoritmen brukes som en nøkkelavledningsfunksjon.

• Database kryptering: Databasen (Realm) brukes til å lagre ikke-hemmelige data. Dataene er kryptert med en tilfeldig 64-byte nøkkel.

• Låsemekanisme: Inntasting av feil passord utløser forsinkelser før påfølgende passordforsøk kan gjøres. Denne mekanismen avskrekker effektivt brute-force passordangrep. Informasjon angående låseparametere, som antall forsøk og varigheten av forsinkelser, er trygt lagret i nøkkelring eller nøkkellager.

Seed-, mnemonic- og databasekrypteringsnøkkelen lagres alltid i kryptert form

• Når ingen beskyttelse er aktivert: Seed-, mnemonic- og Realm-krypteringsnøkkelen lagres direkte i nøkkelring eller nøkkellager uten tilgangskontroll for brukertilstedeværelse.
• Når applås er aktivert: Mnemonikken og frøet krypteres først med applåshemmeligheten og lagres deretter sikkert i nøkkelring eller nøkkellager. Realm-krypteringsnøkkelen lagres også direkte i nøkkelringen eller nøkkellageret.
• Når passordbeskyttelse er aktivert: Mnemonic og frø er kryptert med passordet, mens Realm-krypteringsnøkkelen er kryptert med passordet bare hvis is_storage_encrypted ble satt til true.
• Når både applås og passordbeskyttelse er aktivert: Mnemonic og frø er kryptert med både passord (første) og applås (andre). Realm-krypteringsnøkkelen er kun kryptert med passordet og bare hvis is_storage_encrypted ble satt til true.

Nøkkelbruk

Frøet/mnemonikken lagres i nøkkelring eller nøkkellager og spiller en avgjørende rolle i kryptografiske operasjoner. Når en ny lommebokadresse må genereres eller en transaksjon må signeres, henter vi den nødvendige informasjonen, for eksempel den private nøkkelen, fra dette frøet.

Det er imidlertid viktig å merke seg at den private nøkkelen må lastes inn i minnet under disse operasjonene. Denne nødvendigheten stammer fra begrensningene vi nevnte tidligere om mobillommebøker og mangelen på direkte tilgang til det sikre elementet for transaksjonssignering.

• Transaksjonssignering (sende tokens)
• WalletConnect-datasignering (håndtering av øktforespørsler)
• Legger til en ny lommebok
• Aktivering av testnett-kjeder (legger til testnett-lommebøker)
• Viser mnemonikken
• Verifisering av mnemonikken
• Aktiverer og deaktiverer applås
• Aktivere og deaktivere passordet

Ytterligere biometrisk autentisering utføres for følgende funksjoner:

• Aktiverer applås
• Tørker all data
• Slette en lommebok (konto)
• Aktivere eller deaktivere et passord (i tillegg til henting av applås)
• Åpner applikasjonen
• Flytter applikasjonen i forgrunnen
• Viser utvidede offentlige nøkler
• Koble til en desentralisert applikasjon (dApp)

I tillegg kan passordet være nødvendig for å åpne programmet. Nøkkelring og nøkkellager brukes alltid gjennom reager-native-nøkkelring innpakning:

• Innpakningen genererer en ny nøkkel i nøkkelring eller nøkkellager for hver vare
• Innpakningen er ansvarlig for å sende de riktige konfigurasjonsflaggene for nøkkelring og nøkkellager
• Lommeboken ber alltid omslaget om å konfigurere flaggene slik at enheten må låses opp for å få tilgang til nøkkelen
• En brukertilstedeværelse (biometrisk) sjekk er konfigurert til å være tidsbasert, og kontrollen er gyldig i 5 sekunder; brukertilstedeværelseskontrollen utføres ikke per tilgang

Krypteringsalgoritmen er den samme for alle elementer:

• Nøkkelen er avledet med Argon2id fra en NFC-normalisert hemmelighet
• Saltet for Argon2id er enhetens unike ID
• Krypteringsmodusen er AES-GCM
• Initialiseringsvektoren (IV) for AES er 16 tilfeldige byte
• Auth-taggen for AES må være 16 byte lang

Transaksjonssignering

I tillegg til de tidligere nevnte tiltakene vedrørende nøkkellagring, biometri og passordbeskyttelse, er transaksjonssignering fortsatt et kritisk fokusområde for kontinuerlig forbedring. Som et første skritt har vi implementert flere bemerkelsesverdige tiltak på dette domenet, inkludert:

Transaksjonssimulering

Vi bruker eksterne API-tjenester (som f.eks Blowfish og andre) for å sjekke de mulige nivåene av "alvorlighet" som en transaksjon kan gi brukeren (en risikoscore). Dette går fra full blokkskjerm for mulige ondsinnede transaksjoner (eller meldingssignering) til advarsler om de ulike nivåene av forsiktighet brukeren bør ha før signering eller bekreftelse av en transaksjon. 

Andre tiltak inkluderer:

• Adressevalidering for å sikre at du ikke sender til feil adresse
• Adresser som alltid er synlige i sin helhet for å sikre at brukeren ikke er målrettet mot spesifikke angrep rundt adressesammensetningen
• Nettverksvalidering og advarsler for å sikre at brukeren ikke sender til feil nettverk
• Avgiftskontroll for å sikre at brukeren ikke betaler for mye for en transaksjon

Nettverks personvern

For å beskytte brukernes personvern og personlige data på en måte der disse dataene ikke lekkes på nettverksforespørsler – spesielt til tredjepartstjenester – har vi utviklet en API-gateway til proxy-forespørsler. Denne proxyen lar oss ikke sende brukerforespørsler til tredjepartstjenester og avslører ikke en klients IP til eksterne eller offentlige leverandører. 

Denne backend-tjenesten er i utgangspunktet et API for å spørre etter offentlige blokkjededata. Innenfor lommeboksikkerhetsarkitekturen er formålet å innkapsle denne funksjonaliteten bak en felles API på tvers av alle blokkjeder, slik at Kraken Wallet ikke trenger å implementere blokkjedespesifikk atferd for dataspørring.

Denne backend-tjenesten definerer denne vanlige API-en. Den sender til slutt forespørsler til andre parter som den henter de faktiske dataene fra. Den indekserer ikke blokkjeder selv og opprettholder heller ikke tilstanden.

Sikkerhetsforutsetninger

Sikkerhetsarkitekturen vår opererer på noen få nøkkelantakelser for optimal beskyttelse. Vi antar:

• Brukerens enhet er ikke rootet, og operativsystemet er heller ikke utdatert og utsatt for kritiske sårbarheter som kan gi en angriper tilgang til enhetens minne
• Nøkkelring eller Keystore-pakken gir sterk nok beskyttelse
• Det mobile operativsystemet tilbyr solid sandboxing mellom appens prosesser, og sikrer at minne som inneholder sensitive data som frø administreres riktig

Ekstra funksjonalitet

• Appen opererer etter prinsippet om kun å lagre minimumsdataene den trenger for å kjøre lommeboken
• Ingen tredjepartsanalyser eller programvareutviklingssett for krasjrapportering (SDK-er) brukes på klienten
  • Med vår innsats for ikke å lekke data til tredjeparter, ville det ikke være fornuftig å inkludere ekstra datasporing – noe som betyr at du ikke finner noen analyse- eller krasjrapportprogramvare i klienten
• Ingen over-the-air oppdateringer (utenfor den vanlige oppdateringsflyten for AppStore/Play Store) er tillatt eller implementert på kodebasen
  • Brukeren kan forvente en kompilert programvare som ikke kan oppdateres uten samtykke fra vedkommende
• Tokenliste og omdømmesystem
  • For å hjelpe brukere med å administrere tokens deres, implementerte vi et liste- og omdømmesystem basert på eiendelene levert av Kraken og andre tredjeparter
• NFTs spam
  • En første innsats som vi planlegger å fortsette å forbedre er spam og spam-relatert angrepsdeteksjon, der spam automatisk arkiveres i brukerens mappe

Ekstern sikkerhetsrevisjon

Sikkerheten til vår selvforvaringslommebok ble grundig evaluert gjennom en revisjon utført av Spor av biter, et velrenommert sikkerhetsrevisjonsfirma i bransjen. Denne revisjonen omfattet en detaljert undersøkelse av vår kodebase og klientarkitektur, med sikte på å identifisere og adressere potensielle sikkerhetssårbarheter.

For å sikre åpenhet og gi innsikt i sikkerheten til plattformen vår, er resultatene av denne revisjonen offentlig tilgjengelig. Denne åpne tilgangen lar brukere og interesserte parter gjennomgå funnene i sikkerhetsanalysen utført av Trail of Bits. Rapporten fungerer som en viktig ressurs for å forstå sikkerhetstiltakene vi har på plass og vår forpliktelse til å opprettholde et sikkert miljø for brukerne våre.

Prioritering av sikkerhet, åpenhet og brukerkontroll

Kraken Wallet finner en delikat balanse mellom bekvemmelighet og robust beskyttelse i møte med iboende plattformbegrensninger. Vår tilnærming har alltid vært å begynne med en interoperabel lommebokstruktur som er allment anerkjent. Dette solide grunnlaget legger til rette for at vi kan innovere og legge til nye funksjoner, med målet om å tilby brukerne våre en stadig utviklende sikkerhetsløsning på toppnivå for selvforvaring av kryptoaktiva.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://blog.kraken.com/product/kraken-wallet/kraken-wallet-security