foundation that works to improve the security of software OWASP Top 10 OWASP ASVS OWASP WSTG OWASP MASVS/MSTG https://owasp.org/www-project-mobile-security-testing-guide/ https://owasp.org/www-project-application-security-veri f ication-standard/ https://owasp.org/www-project-web-security-testing-guide/ https://owasp.org/www-project-top-ten/
private key Loosing seed / private key = loosing the account Wallet gives access to several accounts The main challenge is to secure seed / private keys
security baseline should be nearly the same. Threat vectors considerations • Authentication • Local storage • Platform trust • Cryptography • Communication • User education • Supply chain
access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. No sensitive data should be stored locally on the mobile device. Instead, data should be retrieved from a remote endpoint when needed and only be kept in memory. If sensitive data is still required to be stored locally, it should be encrypted using a key derived from hardware backed storage which requires authentication. – OWASP MASVS 4.1, 2.11, 2.12
access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. No sensitive data should be stored locally on the mobile device. Instead, data should be retrieved from a remote endpoint when needed and only be kept in memory. If sensitive data is still required to be stored locally, it should be encrypted using a key derived from hardware backed storage which requires authentication. – OWASP MASVS 4.1, 2.11, 2.12 But what about deanonymisation? Non-custodial wallets are usually fat clients
to deliver the best security guarantees? Is it a f ile? Can you steal it? Can other apps access it? What about integrity? And Encryption? It is a developer’s responsibility to know how the storage works on the platform you use.
decided to pick AES. You need a key length of 256 bits but the password is shorter. You use a hash function SHA256. KDF (Key Derivation Function) Your pick PBKDF2. You need to specify number of rounds for it. Similar to some example in the Internet you pick 2 000.
decided to pick AES. You need a key length of 256 bits but the password is shorter. You use a hash function SHA256. KDF (Key Derivation Function) Your pick PBKDF2. You need to specify number of rounds for it. Similar to some example in the Internet you pick 2 000. 310 000
decided to pick AES. You need a key length of 256 bits but the password is shorter. You use a hash function SHA256. KDF (Key Derivation Function) Your pick PBKDF2. You need to specify number of rounds for it. Similar to some example in the Internet you pick 2 000. 310 000 CBC or GCM mode? Random IV? … ? ? ?
decided to pick AES. You need a key length of 256 bits but the password is shorter. You use a hash function SHA256. KDF (Key Derivation Function) Your pick PBKDF2. You need to specify number of rounds for it. Similar to some example in the Internet you pick 2 000. 310 000 CBC or GCM mode? Random IV? … ? ? ? Don’t roll your own crypto Use Themis https://github.com/cossacklabs/themis Use libsodium
uses Stanford Javascript Crypto Library (SJCL) for synchronous random values generation. SJCL random values generator relies on mouse movements and keyboard listeners. React Native mobile app example
engineers: https://www.cossacklabs.com/blog/crypto-wallets-security/ [Article] Security of React Native libraries: the bad, the worse and the ugly: https://www.cossacklabs.com/blog/react-native-libraries-security/ [Article] React Native security: things to keep in mind: https://www.cossacklabs.com/blog/react-native-app-security/ [Slides] Why can’t developers make it secure: https://speakerdeck.com/julep/why-cant-developers-make-it-secure