Wij zijn van mening dat de veiligste mobiele crypto-portemonnee er een is die de inherente beperkingen van het mobiele besturingssysteem overwint. Op iOS ondersteunt Apple's CryptoKit bijvoorbeeld niet de secp256k1 elliptische curve, een standaard voor Bitcoin, Ethereum en vele andere blockchains.

Deze beperking beperkt ontwikkelaars in het gebruik van het beveiligde element van apparaten voor sleutelopslag en het ondertekenen van transacties. Als gevolg hiervan worden mobiele crypto-wallets geclassificeerd als hot wallets, omdat ze beide verbonden zijn met internet en transacties ondertekenen buiten een beveiligd element met behulp van een software-implementatie van de cryptografische algoritmen.

Dit betekent dat de privésleutels – in ieder geval tijdens het ondertekenen – zichtbaar moeten zijn in het geheugen van de sandbox-app-omgeving. Hierdoor zijn ze meer blootgesteld aan potentiële bedreigingen dan een portemonnee die een beveiligd element gebruikt om transacties te ondertekenen.

Despite the inability to perform the signing on the secure elements directly, which would offer increased protection, we have committed to providing an open-source mobile crypto wallet that prioritizes security, transparency and user control.

Onze beveiligingsarchitectuur is speciaal gebouwd om:

• Ondersteuning van meerdere blockchains
• Genereer privésleutels met een hoge entropie, een mate van onvoorspelbaarheid die de veiligheid vergroot
• Maak gebruik van beproefde cryptografie om de privésleutels van gebruikers veilig te versleutelen, waarbij u profiteert van de beveiligingshardware van mobiele telefoons en de beveiligingsfuncties van het besturingssysteem
• Bied verbeterde beveiliging met een door de gebruiker gegenereerd wachtwoord voor geavanceerde gebruikers die een extra coderingsniveau wensen (bovenop de OS-sleutelhangerbeveiliging voor de decoderingssleutel)
• Creëer een solide basis voor toekomstige integratie van nieuwe typen sleutelbeheer, zoals hardware wallets en op MPC-quorums gebaseerde systemen

Het opensourcevoordeel

Als een van de fundamentele veiligheidsprincipes Kraken portemonnee is gratis en open source-software, verdeeld onder de MIT-licentie. Door vanaf de basis een nieuwe portemonnee te bouwen, was het voor ons belangrijk om het open source en gedistribueerde ecosysteem te helpen bevorderen.

Zonder open-sourcecode zou Kraken Wallet een grote hoeveelheid vertrouwen vereisen zonder transparantie. Dit zou cliënten minder bescherming bieden; u kunt de client niet zelf verifiëren, wijzigen of uitvoeren als u dat wilt. “Vertrouw niet, verifieer!” is niet alleen een stelregel van de sector, het is een van onze leidende principes.

Door open source te gebruiken, voldoet onze software aan twee fundamentele doelen die we in eerste instantie voor dit product hebben gesteld: verifieerbare, controleerbare vertrouwensminimalisatie:

• Controleerbaarheid: De mogelijkheid om te verifiëren dat de beveiligingsaannames in deze blogpost waar zijn. Iedereen kan kijk naar de broncode om specifiek te begrijpen wat er wel en niet in deze portemonnee wordt gedaan. 

• Controleerbaarheid: De mogelijkheid om te verifiëren dat de output van onze beveiligingsimplementatie correct is en hierover verslag uit te brengen als dit niet het geval is. We hebben interne en externe teams ingeschakeld om voorafgaand aan de release meerdere keren beveiligingsaudits uit te voeren. In de toekomst kan iedereen de code controleren en een rapport over zijn bevindingen opstellen.

Sleutelgeneratie en sleutelimport

React Native is weliswaar een krachtig hulpmiddel, maar heeft geen ingebouwde cryptomodule. Om hier omheen te navigeren, hebben we een pure-js-implementatie (crypto-browserify) van de cryptomodule van NodeJS gebruikt. De methode crypto.randomBytes() – die de feitelijke willekeurige bytes genereert die we nodig hebben tijdens het genereren van de sleutel – wordt afgehandeld door de react-native-get-willekeurige-waarden polyvulling.

React-native-get-random-values ​​gebruikt native code om de Cryptographically Secure Pseudorandom Number Generator (CSPRNG) te gebruiken die op het apparaat beschikbaar is om willekeurige getallen te genereren. Op vrijwel alle moderne apparaten wordt deze generator voor willekeurige getallen ondersteund door een veilige hardwaregenerator voor willekeurige getallen.

Tijdens de initialisatie van de portefeuille halen we entropie uit de CSPRNG en zetten deze om in een geheugensteuntje met behulp van gevestigde npm-pakketten (BIP32, BIP39).

Sleutels worden geconverteerd, opgeslagen en aan de gebruiker gepresenteerd onder de BIP39-standaard, die een eenvoudig te back-up geheugenmethode biedt met interoperabiliteit voor de meeste portemonnees in het ecosysteem. De importfunctie ondersteunt het herstel van BIP39-compatibele zaden, die de beste interoperabiliteit in het ecosysteem bieden. 

Sleutelbeheer 

Kraken Wallet bevat twee geheime waarden – het zaad en het geheugensteuntje – en meerdere niet-geheime (maar nog steeds privé) waarden zoals portemonnee-adressen, portemonnee-namen en beschrijvingen van transacties.

Privésleutelmateriaal (seed/ezelsbruggetje) wordt opgeslagen in Keychain (op iOS) en Keystore (op Android). Publiek sleutelmateriaal en niet-gevoelige gegevens (uitgebreide publieke sleutels, adressen en beschrijvingen) worden opgeslagen in de gecodeerde database van de applicatie (met behulp van Rijk).

Er zijn meerdere beveiligingsmaatregelen die de gegevens beschermen:

• App-vergrendeling: Een willekeurig gegenereerde tekenreeks van 64 bytes opgeslagen in Keychain of Keystore. De toegang tot het geheim wordt beschermd door vereisten voor de aanwezigheid van de gebruiker: biometrische authenticatie of wachtwoordauthenticatie.

• Wachtwoord: door de gebruiker verstrekt en niet op een apparaat bewaard. In plaats daarvan moet de gebruiker het wachtwoord handmatig opgeven wanneer de toepassing daarom vraagt. De portemonnee bepaalt of het wachtwoord nodig is door twee vlaggen (is_storage_encrypted en is_seed_encrypted) te raadplegen die zijn opgeslagen in Keychain of Keystore. Het Argon2-algoritme wordt gebruikt als sleutelafleidingsfunctie.

• Database-encryptie: De database (Realm) wordt gebruikt om niet-geheime gegevens op te slaan. De gegevens worden gecodeerd met een willekeurige sleutel van 64 bytes.

• Vergrendelingsmechanisme: het invoeren van een onjuist wachtwoord veroorzaakt vertragingen voordat volgende wachtwoordpogingen kunnen worden gedaan. Dit mechanisme schrikt effectief wachtwoordaanvallen met brute kracht af. Informatie over lockout-parameters, zoals het aantal pogingen en de duur van vertragingen, wordt veilig opgeslagen in Keychain of Keystore.

De zaad-, geheugensteun- en database-encryptiesleutel worden altijd in gecodeerde vorm opgeslagen

• Wanneer er geen beveiligingen zijn ingeschakeld: De zaad-, geheugensteun- en Realm-coderingssleutel worden rechtstreeks in Keychain of Keystore opgeslagen zonder toegangscontrole door de aanwezigheid van de gebruiker.
• Wanneer app-vergrendeling is geactiveerd: Het ezelsbruggetje en het zaad worden eerst gecodeerd met het app-slotgeheim en vervolgens veilig opgeslagen in Keychain of Keystore. De Realm-encryptiesleutel wordt ook rechtstreeks opgeslagen in de Keychain of Keystore.
• Wanneer wachtwoordbeveiliging is ingeschakeld: Het geheugensteuntje en het zaad worden gecodeerd met het wachtwoord, terwijl de Realm-coderingssleutel alleen met het wachtwoord wordt gecodeerd als is_storage_encrypted is ingesteld op true.
• Wanneer zowel app-vergrendeling als wachtwoordbeveiliging zijn ingeschakeld: Het geheugensteuntje en het zaadje zijn gecodeerd met zowel een wachtwoord (eerste) als app-vergrendeling (tweede). De Realm-coderingssleutel wordt alleen gecodeerd met het wachtwoord en alleen als is_storage_encrypted is ingesteld op true.

Sleutelgebruik

Het zaad/ezelsbruggetje wordt opgeslagen in Keychain of Keystore en speelt een cruciale rol bij cryptografische bewerkingen. Wanneer er een nieuw portemonnee-adres moet worden gegenereerd of een transactie moet worden ondertekend, ontlenen we uit dit zaad de benodigde informatie, zoals de privésleutel.

Het is echter belangrijk op te merken dat de privésleutel tijdens deze bewerkingen in het geheugen moet worden geladen. Deze noodzaak komt voort uit de beperkingen die we eerder noemden met betrekking tot mobiele portemonnees en het gebrek aan directe toegang tot het beveiligde element voor het ondertekenen van transacties.

• Transactie ondertekenen (tokens verzenden)
• WalletConnect-gegevensondertekening (sessieverzoeken afhandelen)
• Een nieuwe portemonnee toevoegen
• Testnet-ketens inschakelen (testnet-wallets toevoegen)
• Het geheugensteuntje weergeven
• Het ezelsbruggetje verifiëren
• App-vergrendeling in- en uitschakelen
• Het wachtwoord in- en uitschakelen

Voor de volgende functionaliteiten wordt aanvullende biometrische authenticatie uitgevoerd:

• App-vergrendeling inschakelen
• Alle gegevens wissen
• Een portemonnee (account) verwijderen
• Een wachtwoord in- of uitschakelen (naast het ophalen van de app-vergrendeling)
• De applicatie openen
• Verplaats de applicatie naar de voorgrond
• Uitgebreide openbare sleutels bekijken
• Verbinding maken met een decentrale applicatie (dApp)

Bovendien kan het wachtwoord vereist zijn om de applicatie te openen. Keychain en Keystore worden altijd gebruikt via de react-native-sleutelhanger wikkel:

• De wrapper genereert voor elk item een ​​nieuwe sleutel in Keychain of Keystore
• De wrapper is verantwoordelijk voor het doorgeven van de juiste configuratievlaggen voor Keychain en Keystore
• De portemonnee vraagt ​​de wrapper altijd om de vlaggen zo te configureren dat het apparaat moet worden ontgrendeld om toegang te krijgen tot de sleutel
• Een controle op de aanwezigheid van de gebruiker (biometrische controle) is geconfigureerd om op tijd gebaseerd te zijn en de controle is 5 seconden geldig; de controle op de aanwezigheid van de gebruiker wordt niet per toegang uitgevoerd

Het versleutelingsalgoritme is voor alle items hetzelfde:

• De sleutel is met Argon2id afgeleid van een NFC-genormaliseerd geheim
• Het zout voor Argon2id is de unieke ID van het apparaat
• De coderingsmodus is AES-GCM
• De initialisatievector (IV) voor AES is 16 willekeurige bytes
• De auth-tag voor AES moet 16 bytes lang zijn

Ondertekening van transactie

Naast de eerder genoemde maatregelen met betrekking tot sleutelopslag, biometrie en wachtwoordbeveiliging blijft het ondertekenen van transacties een cruciaal aandachtsgebied voor voortdurende verbetering. Als eerste stap hebben we op dit gebied een aantal opmerkelijke maatregelen geïmplementeerd, waaronder:

Transactiesimulatie

Wij maken gebruik van externe API-diensten (zoals Blowfish en anderen) om de mogelijke niveaus van “ernst” te controleren die een transactie voor de gebruiker kan opleveren (een risicoscore). Dit gaat van een volledig blokkeerscherm voor mogelijke kwaadaardige transacties (of het ondertekenen van berichten) tot waarschuwingen over de verschillende niveaus van voorzichtigheid die de gebruiker moet hebben voordat hij een transactie ondertekent of bevestigt. 

Andere maatregelen zijn onder meer:

• Adresvalidatie om ervoor te zorgen dat u niet naar een verkeerd adres verzendt
• Adressen die altijd in hun geheel zichtbaar zijn om ervoor te zorgen dat de gebruiker niet het doelwit is van specifieke aanvallen rond de adressamenstelling
• Netwerkvalidatie en waarschuwingen om ervoor te zorgen dat de gebruiker niet naar het verkeerde netwerk verzendt
• Voer sanity checks uit om er zeker van te zijn dat de gebruiker niet te veel betaalt voor een transactie

Netwerkprivacy

Om de privacy en persoonlijke gegevens van gebruikers te beschermen op een manier waarbij deze gegevens niet lekken bij netwerkverzoeken (vooral naar services van derden) hebben we een API-gateway voor proxyverzoeken ontwikkeld. Met deze proxy kunnen we gebruikersverzoeken niet doorgeven aan diensten van derden en wordt het IP-adres van een klant niet bekendgemaakt aan externe of openbare providers. 

Deze backend-service is in feite een API voor het opvragen van openbare blockchain-gegevens. Binnen de portemonnee-beveiligingsarchitectuur is het doel om deze functionaliteit in te kapselen achter een gemeenschappelijke API voor alle blockchains, zodat Kraken Wallet geen blockchain-specifiek gedrag hoeft te implementeren voor het opvragen van gegevens.

Deze backend-service definieert deze gemeenschappelijke API. Uiteindelijk stuurt het verzoeken door naar andere partijen waarvan het de daadwerkelijke gegevens ophaalt. Het indexeert zelf geen blockchains en onderhoudt ook geen status.

Beveiligingsaannames

Onze beveiligingsarchitectuur werkt op basis van enkele belangrijke aannames voor optimale bescherming. Wij veronderstellen:

• Het apparaat van de gebruiker is niet geroot, het besturingssysteem is ook niet verouderd en gevoelig voor kritieke kwetsbaarheden die een aanvaller toegang kunnen geven tot het apparaatgeheugen
• Het Keychain- of Keystore-pakket biedt voldoende bescherming
• Het mobiele besturingssysteem biedt solide sandboxing tussen de processen van apps, zodat het geheugen met gevoelige gegevens zoals zaden op de juiste manier wordt beheerd

Extra functionaliteit

• De app werkt volgens het principe om alleen de minimale gegevens op te slaan die nodig zijn om de portemonnee te laten werken
• Op de client worden geen analyses van derden of softwareontwikkelingskits (SDK's) voor crashrapportage gebruikt
  • Met onze inspanningen om geen gegevens naar derden te lekken, zou het geen zin hebben om extra gegevenstracking op te nemen – wat betekent dat u geen analyse- of crashrapportsoftware in de client zult vinden
• Er zijn geen draadloze updates (buiten de reguliere AppStore/Play Store-updatestroom) toegestaan ​​of geïmplementeerd op de codebase
  • De gebruiker kan een gecompileerd stukje software verwachten dat niet kan worden bijgewerkt zonder toestemming van de gebruiker
• Tokenslijst en reputatiesysteem
  • Om gebruikers te helpen hun tokens te beheren, hebben we een lijst- en reputatiesysteem geïmplementeerd op basis van de activa van Kraken en andere derde partijen
• NFT's spam
  • Een eerste poging die we willen blijven verbeteren is de detectie van spam en spamgerelateerde aanvallen, waarbij spam automatisch wordt gearchiveerd in de map van de gebruiker.

Externe veiligheidsaudit

De veiligheid van onze zelfbewarende portemonnee werd rigoureus geëvalueerd tijdens een audit uitgevoerd door Spoor van Bits, een gerenommeerd beveiligingsauditbureau in de branche. Deze audit omvatte een gedetailleerd onderzoek van onze codebase en clientarchitectuur, gericht op het identificeren en aanpakken van potentiële beveiligingsproblemen.

Om transparantie te garanderen en inzicht te geven in de veiligheid van ons platform zijn de resultaten van deze audit openbaar beschikbaar. Dankzij deze open toegang kunnen gebruikers en geïnteresseerden de bevindingen van de beveiligingsanalyse van Trail of Bits inzien. Het rapport dient als een belangrijk hulpmiddel bij het begrijpen van de beveiligingsmaatregelen die we hebben genomen en onze inzet voor het handhaven van een veilige omgeving voor onze gebruikers.

Prioriteit geven aan beveiliging, transparantie en gebruikerscontrole

Kraken Wallet vindt een delicaat evenwicht tussen gemak en robuuste bescherming in het licht van inherente platformbeperkingen. Onze aanpak is altijd geweest om te beginnen met een interoperabele portefeuillestructuur die algemeen wordt erkend. Deze solide basis vormt voor ons de weg om te innoveren en nieuwe mogelijkheden toe te voegen, met als doel onze gebruikers een steeds evoluerende, hoogwaardige beveiligingsoplossing te bieden voor het zelf beheren van hun crypto-activa.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://blog.kraken.com/product/kraken-wallet/kraken-wallet-security