Vi tror att den säkraste mobila kryptoplånboken är en som övervinner de inneboende begränsningarna i sitt mobila operativsystem. Till exempel, på iOS, stöder inte Apples CryptoKit secp256k1 elliptisk kurva, en standard för Bitcoin, Ethereum och många andra blockkedjor.

Denna begränsning hindrar utvecklare från att använda den säkra delen av enheter för nyckellagring och transaktionssignering. Som ett resultat av detta klassificeras mobila kryptoplånböcker som heta plånböcker eftersom de både är anslutna till internet och signerar transaktioner utanför ett säkert element med hjälp av en mjukvaruimplementering av de kryptografiska algoritmerna.

Det betyder att de privata nycklarna måste vara exponerade – åtminstone under signering – i minnet av den sandlådeformade appmiljön. Detta gör dem mer utsatta för potentiella hot än en plånbok som använder ett säkert element för att signera transaktioner.

Trots oförmågan att utföra signeringen på de säkra elementen direkt, vilket skulle ge ökat skydd, har vi åtagit oss att tillhandahålla en öppen källkod mobil kryptoplånbok som prioriterar säkerhet, transparens och användarkontroll.

Vår säkerhetsarkitektur är specialbyggd för att:

• Stöd flera blockkedjor
• Generera privata nycklar med hög entropi, ett mått på oförutsägbarhet som stärker säkerheten
• Utnyttja stridstestad kryptografi för att säkert kryptera användarnas privata nycklar, utnyttja mobiltelefonernas säkerhetshårdvara och OS-säkerhetsfunktioner
• Erbjud förbättrad säkerhet med ett användargenererat lösenord för avancerade användare som vill ha en extra krypteringsnivå (utöver OS-nyckelringsskyddet för dekrypteringsnyckeln)
• Skapa en solid grund för framtida inkorporering av nya nyckelhanteringstyper, såsom hårdvaruplånböcker och MPC-quorum-baserade system

Fördelen med öppen källkod

Som en av dess grundläggande säkerhetsprinciper, Kraken plånbok är gratis och öppen källkod, fördelat under MIT-licensen. Att bygga en ny plånbok från grunden var det viktigt för oss att hjälpa till att främja öppen källkod och det distribuerade ekosystemet.

Utan öppen källkod skulle Kraken Wallet kräva en stor mängd förtroende utan transparens. Detta skulle ge kunderna mindre skydd; du kunde inte verifiera, modifiera eller köra klienten själv om du ville. "Lita inte på, verifiera!" är inte bara en branschmaxim, det är en av våra vägledande principer.

Open sourcing vår programvara uppfyller två grundläggande mål som vi initialt satte upp för den här produkten: verifierbar, granskbar förtroendeminimering:

• Verifierbarhet: Möjligheten att verifiera att säkerhetsantagandena som presenteras i detta blogginlägg är sanna. Vem som helst kan titta på källkoden för att specifikt förstå vad som görs och inte görs i denna plånbok. 

• Granskning: Möjligheten att verifiera att resultatet av vår säkerhetsimplementering är korrekt och rapportera tillbaka när det inte är det. Vi har engagerat interna och externa team för att utföra säkerhetsrevisioner flera gånger före release. Framöver kan vem som helst granska koden och producera en rapport om sina resultat.

Nyckelgenerering och nyckelimport

React Native, även om det är ett kraftfullt verktyg, har ingen inbyggd kryptomodul. För att navigera runt detta använde vi en pure-js-implementation (crypto-browserify) av NodeJS:s kryptomodul. Metoden crypto.randomBytes() – som genererar de faktiska slumpmässiga bytes som vi behöver under nyckelgenerering – hanteras av reagera-infödda-få-slumpmässiga-värden polyfill.

React-native-get-random-values ​​använder inbyggd kod för att använda Cryptographically Secure Pseudorandom Number Generator (CSPRNG) som finns på enheten för att generera slumptal. På praktiskt taget alla moderna enheter stöds denna slumptalsgenerator av en säker hårdvarugenerator för slumptal.

Under plånboksinitiering drar vi entropi från CSPRNG och omvandlar den till ett mnemoniskt frö med hjälp av väletablerade npm-paket (BIP32, BIP39).

Nycklar konverteras, lagras och presenteras för användaren under BIP39-standarden, som erbjuder en mnemonisk metod som är lätt att säkerhetskopiera med interoperabilitet för de flesta plånböcker i ekosystemet. Importfunktionen stöder återhämtning av BIP39-kompatibla frön, vilket ger den bästa interoperabiliteten i ekosystemet. 

Nyckelhantering 

Kraken Wallet har två hemliga värden – fröet och mnemoniken – och flera icke-hemliga (men fortfarande privata) värden som plånboksadresser, plånboksnamn och beskrivningar av transaktioner.

Privat nyckelmaterial (seed/mnemonic) lagras i Keychain (på iOS) och Keystore (på Android). Public key material och icke-känsliga data (utökade publika nycklar, adresser och beskrivningar) lagras i applikationens krypterade databas (med hjälp av Rike).

Det finns flera säkerhetskontroller som skyddar data:

• Applås: En slumpmässigt genererad sträng på 64 byte lagrad i nyckelring eller nyckellager. Åtkomst till hemligheten är skyddad med krav på användarnärvaro – biometrisk autentisering eller lösenordsautentisering.

• Lösenord: Tillhandahålls av användaren och förvaras inte på en enhet. Istället måste användaren ange lösenordet manuellt närhelst applikationen ber om det. Plånboken avgör om lösenordet behövs genom att konsultera två flaggor (is_storage_encrypted och is_seed_encrypted) lagrade i nyckelring eller nyckellager. Argon2-algoritmen används som en nyckelhärledningsfunktion.

• Databaskryptering: Databasen (Realm) används för att lagra icke-hemlig data. Data krypteras med en slumpmässig 64-byte nyckel.

• Lockout mekanism: Att ange ett felaktigt lösenord utlöser förseningar innan efterföljande lösenordsförsök kan göras. Denna mekanism avskräcker effektivt brute-force lösenordsattacker. Information om låsningsparametrar, såsom antal försök och förseningars varaktighet, lagras säkert i Nyckelring eller Nyckellager.

Seed-, mnemoniken och databaskrypteringsnyckeln lagras alltid i krypterad form

• När inga skydd är aktiverade: Seed-, mnemonic- och Realm-krypteringsnyckeln lagras direkt i Nyckelring eller Keystore utan åtkomstkontroll för användarnärvaro.
• När applås är aktiverat: Mnemoniken och fröet krypteras först med applåshemligheten och lagras sedan säkert i nyckelring eller nyckelbutik. Realm-krypteringsnyckeln lagras också direkt i nyckelringen eller nyckelarkivet.
• När lösenordsskydd är aktiverat: Mnemonic och seed är krypterade med lösenordet, medan Realm-krypteringsnyckeln är krypterad med lösenordet endast om is_storage_encrypted var satt till true.
• När både applås och lösenordsskydd är aktiverade: Mnemoniken och fröet är krypterade med både lösenord (första) och applås (andra). Realm-krypteringsnyckeln krypteras endast med lösenordet och endast om is_storage_encrypted var satt till true.

Nyckelanvändning

Fröet/mnemoniken lagras i Keychain eller Keystore och spelar en avgörande roll i kryptografiska operationer. När en ny plånboksadress behöver genereras eller en transaktion måste signeras, hämtar vi nödvändig information, såsom den privata nyckeln, från detta frö.

Det är dock viktigt att notera att den privata nyckeln måste laddas in i minnet under dessa operationer. Denna nödvändighet härrör från de begränsningar vi nämnde tidigare om mobila plånböcker och avsaknaden av direkt tillgång till det säkra elementet för transaktionssignering.

• Transaktionssignering (skicka tokens)
• WalletConnect-datasignering (hantering av sessionsförfrågningar)
• Lägger till en ny plånbok
• Aktivera testnätkedjor (lägga till testnätplånböcker)
• Visar minnesmärket
• Verifierar minnesminnet
• Aktivera och inaktivera applås
• Aktivera och inaktivera lösenordet

Ytterligare biometrisk autentisering utförs för följande funktioner:

• Aktiverar applås
• Rensar all data
• Ta bort en plånbok (konto)
• Aktivera eller inaktivera ett lösenord (utöver applåshämtningen)
• Öppnar applikationen
• Flyttar applikationen till förgrunden
• Visa utökade offentliga nycklar
• Ansluta till en decentraliserad applikation (dApp)

Dessutom kan lösenordet behövas för att öppna programmet. Nyckelring och Keystore används alltid genom reagera-native-nyckelring omslag:

• Omslaget genererar en ny nyckel i nyckelring eller nyckellager för varje föremål
• Omslaget ansvarar för att skicka rätt konfigurationsflaggor för nyckelring och nyckellager
• Plånboken ber alltid omslaget att konfigurera flaggorna så att enheten måste låsas upp för att komma åt nyckeln
• En kontroll av användarnärvaro (biometrisk) är konfigurerad att vara tidsbaserad och kontrollen är giltig i 5 sekunder; användarnärvarokontrollen utförs inte per åtkomst

Krypteringsalgoritmen är densamma för alla objekt:

• Nyckeln härleds med Argon2id från en NFC-normaliserad hemlighet
• Saltet för Argon2id är enhetens unika ID
• Krypteringsläget är AES-GCM
• Initieringsvektorn (IV) för AES är 16 slumpmässiga byte
• Auth-taggen för AES måste vara 16 byte lång

Transaktionssignering

Utöver de tidigare nämnda åtgärderna avseende nyckellagring, biometri och lösenordsskydd är transaktionssignering fortfarande ett kritiskt fokusområde för ständiga förbättringar. Som ett första steg har vi implementerat flera anmärkningsvärda åtgärder på detta område, inklusive:

Transaktionssimulering

Vi använder externa API-tjänster (t.ex blåsfisk och andra) för att kontrollera de möjliga nivåerna av "allvarlighet" som en transaktion kan ge användaren (en riskpoäng). Detta går från hel blockeringsskärm för eventuella skadliga transaktioner (eller meddelandesignering) till varningar om de olika nivåerna av försiktighet som användaren bör ha innan de signerar eller bekräftar en transaktion. 

Andra åtgärder inkluderar:

• Adressvalidering för att säkerställa att du inte skickar till fel adress
• Adresser som alltid är synliga i sin helhet för att säkerställa att användaren inte riktas mot specifika attacker kring adresssammansättning
• Nätverksvalidering och varningar för att säkerställa att användaren inte skickar till fel nätverk
• Avgiftskontroller för att säkerställa att användaren inte betalar för mycket för en transaktion

Nätverksintegritet

För att skydda användarnas integritet och personliga data på ett sätt där dessa data inte läcker på nätverksbegäranden – särskilt till tredjepartstjänster – har vi utvecklat en API-gateway till proxyförfrågningar. Denna proxy tillåter oss att inte skicka användarförfrågningar till tredjepartstjänster och avslöjar inte en klients IP till externa eller offentliga leverantörer. 

Denna backend-tjänst är i grunden ett API för att fråga offentlig blockchain-data. Inom plånbokssäkerhetsarkitekturen är dess syfte att kapsla in denna funktionalitet bakom ett gemensamt API över alla blockkedjor så att Kraken Wallet inte behöver implementera blockkedjespecifika beteenden för dataförfrågningar.

Denna backend-tjänst definierar detta gemensamma API. Den skickar slutligen förfrågningar till andra parter från vilka den hämtar den faktiska informationen. Den indexerar inte blockkedjor själv och upprätthåller inte heller tillstånd.

Säkerhetsantaganden

Vår säkerhetsarkitektur bygger på några viktiga antaganden för optimalt skydd. Vi antar:

• Användarens enhet är inte rotad, inte heller är operativsystemet föråldrat och mottagligt för kritiska sårbarheter som kan ge en angripare åtkomst till enhetens minne
• Nyckelring eller Keystore-paketet ger tillräckligt starkt skydd
• Det mobila operativsystemet erbjuder solid sandboxning mellan appars processer, vilket säkerställer att minne som innehåller känslig data som frön hanteras på rätt sätt

Ytterligare funktioner

• Appen fungerar enligt principen att endast lagra den minsta data den behöver för att köra plånboken
• Inga tredjepartsanalyser eller programvaruutvecklingskit (SDK) för kraschrapportering används på klienten
  • Med våra ansträngningar att inte läcka data till tredje part skulle det inte vara meningsfullt att inkludera extra dataspårning – vilket innebär att du inte hittar någon analys- eller kraschrapportprogramvara i klienten
• Inga trådlösa uppdateringar (utanför det vanliga uppdateringsflödet för AppStore/Play Store) är tillåtna eller implementerade på kodbasen
  • Användaren kan förvänta sig en kompilerad mjukvara som inte kan uppdateras utan deras samtycke
• Tokenlista och ryktesystem
  • För att hjälpa användare att hantera sina tokens implementerade vi ett list- och ryktesystem baserat på tillgångarna från Kraken och andra tredje parter
• NFTs spam
  • En första ansträngning som vi planerar att fortsätta förbättra är skräppost- och spam-relaterad attackdetektering, där skräppost automatiskt arkiveras i användarens mapp

Extern säkerhetsrevision

Säkerheten för vår egenvårdsplånbok utvärderades noggrant genom en revision utförd av Trail of Bits, ett välrenommerat säkerhetsrevisionsföretag i branschen. Denna granskning omfattade en detaljerad granskning av vår kodbas och klientarkitektur, i syfte att identifiera och åtgärda potentiella säkerhetsbrister.

För att säkerställa transparens och ge insikt i säkerheten för vår plattform är resultaten av denna granskning offentligt tillgängliga. Denna öppna åtkomst tillåter användare och intresserade parter att granska resultaten av säkerhetsanalysen utförd av Trail of Bits. Rapporten fungerar som en viktig resurs för att förstå de säkerhetsåtgärder vi har på plats och vårt engagemang för att upprätthålla en säker miljö för våra användare.

Prioritering av säkerhet, transparens och användarkontroll

Kraken Wallet har en delikat balans mellan bekvämlighet och robust skydd inför inneboende plattformsbegränsningar. Vår strategi har alltid varit att börja med en interoperabel plånboksstruktur som är allmänt erkänd. Denna solida grund sätter scenen för oss att förnya och lägga till nya möjligheter, med målet att erbjuda våra användare en ständigt utvecklande säkerhetslösning på toppnivå för att själv förvara sina kryptotillgångar.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://blog.kraken.com/product/kraken-wallet/kraken-wallet-security