Mobile app security audit

[i5hi]

No description provided.

[i5hi]

This will be last issue to close at pre-release of the mobile wallet.

[i5hi]

• Ensure private key data is encrypted at rest.

• Free pointers returned by libstackmate ffi after use: https://medium.com/flutter-community/using-ffi-on-flutter-plugins-to-run-native-rust-code-d64c0f14f9c2

• Wrap libstackmate ffi around strong types.

• Sanitize all functions that take inputs from users or servers. Use regex tools to enforce strict rules beyond basic type checks.

• Mark all sections of code that make calls to servers. This makes it easy for auditors to verify how the app interacts with various servers.

• Helpful error handling.

Note: Cryptographic security is all outsourced to libstackmate - with the exception of hive and flutter_secure_storage - which is already audited to ensure strong encryption. Focus from the dart end is on how cryptographic outputs are handled and stored.

[i5hi]

@qurbat Add some resources and pointers in addition to the above, that you think will be useful for us to keep in mind during development as well as tools and processes that we could use for auditing.

[i5hi]

MOBSF

[qurbat]

apkleaks should be useful for URL and secret discovery.

[qurbat]

• Sanitize all functions that take inputs from users or servers. Use regex tools to enforce strict rules beyond basic type checks.

• Mark all sections of code that make calls to servers. This makes it easy for auditors to verify how the app interacts with various servers.

I can take a look at these once completed.

[qurbat]

An audit of libstackmate might also be necessary since it handles cryptography.

[i5hi]

We just bumped into this, where we had a word repeat. Apparently there is always a 12.7% chance of this happening.

https://bitcoin.stackexchange.com/questions/59904/does-bip39-mnemonic-construction-avoid-repeating-words

Libstackmate currently uses a CSPRNG - rust::rand::OSRng, which uses random OS data to create entropy for your seed.

This is the starting point of libstackmate. I'll make a document, which refers to all the cryptographic methods being used.

[i5hi]

This (keygen) is actually the main point where libstackmate needs to be audited because the rest is outsourced to bdk.

It will soon support tor as well, then that will need separate auditing, on how exactly tor is being configured to ensure its being used correctly. tor in rust is really straight forward, you just set the config and run it as a daemon. So its all in the config parameters - around 5-10 of them. The main thing is that each time you start the tor daemon with the app, you use a new random key to access tor_control so that third party apps can't hijack our tor instance.