Xaman wallet security assurance and improvements

1. Determining the security assessment scope

• We performed risk and threat modelling and formulated the most high-risk threats: critical exploits, secure storage of private keys, and potential transaction fraud.
• Given the self-custodial nature of Xaman, the OWASP MASVS v1.5 served as the security baseline. We excluded certain requirements (such as the V8 Resilience Requirements), which were out of scope. At the same time, we added relevant requirements from the OWASP ASVS v4.0.2 (such as security HTTP headers during network communication). As a result, the assessment had a baseline of 65 security requirements.
• Splitting the assessment into sections: design issues, cryptographic layer, application security, platform security, code quality, infrastructure, supply chain issues.

2. Triaging discovered issues

• We found no critical issues, some high-priority bugs and risky design decisions, and recommended several improvements.
• Security issues were categorised as broken, missing, or in need of enhancements. We evaluated their impact as high, medium, or low. This classification enabled the development team to prioritise security issues effectively and understand the consequences of accepting risks.

3. Highlighting application security and platform trust issues

• Mobile applications should incorporate numerous small security controls:
  • blurring the application screen to hide sensitive data when app is in the background;
  • restricting access for 3rd party keyboards;
  • configuring web views and deep links properly;
  • cleaning up sensitive data in case of suspicious user activity.
• Xaman uses two types of local storage: secret storage in a Keychain/Keystore and an encrypted database for the user data (profile, accounts, settings, etc.). We assessed the storage structure and encryption logic and recommended binding encryption to the specific application installation to prevent data stealing.

4. Migrating to modern state of the art cryptography

• We raised concerns regarding cryptographic procedures, highlighting issues with implementation and questionable design choices. Although these concerns may not have resulted in immediate vulnerabilities, their accumulation is a ticking time bomb.
• Following the assessment feedback, the XRPL Labs team, together with Cossack Labs team, re-designed and re-implemented the entire cryptographic layer, responsible for application-level encryption and sensitive data storage, introducing the "v2" encryption scheme.
• This substantial update to the encryption layer effectively fixed 82% of the weaknesses identified in the original cryptography section.

5. Nurturing xApps community

• xApps are web applications, built to facilitate interaction with the decentralized XRP Ledger. xApps enhance functionality of the wallet, and allow users to interact with specific ledger features in a more user friendly way. Many xApps improve the user experience, but can potentially open security risks.
• To ensure a trustworthy xApps community we recommended implementing additional measures: periodically inspecting xApps, educating users about potential threats, explaining which xApp behaviours could be suspicious, allowing users to flag xApps they don't trust, and so on.

6. Improving security posture and processes

• With the primary objectives of enhancing Xaman app security in mind, our recommendations were centred around establishing robust defences for future application development.
• Implementing such protections could significantly “raise the bar” for attackers and reduce the likelihood of incidents beyond the direct control of application developers.
• For instance, secure development operations can be improved by configuring linters and source code analysers, implementing the dependency management process, and thoroughly enumerating and comparing application permissions.
• The development team created a security roadmap to further improve the security of the Xaman app.