The Trinity threat modelling report (available here) produced by Cybersecurity Lab at COMSATS University Islamabad, outlines several important threats. In the interest of full transparency, this article outlines the mitigation efforts that the Trinity team have undertaken, to provide the utmost security for all end users.
Due to inherent security issues in relation to the Android clipboard, it is advised to avoid clipboard use with sensitive data. Unlike the “walled garden” found in iOS, Android is less restrictive with regards to the capabilities of an app. As a result, any app can read and modify the data stored on the clipboard — even when the app is in the background. This presents a potential attack vector in the Trinity onboarding process. Once the user copies the seed to the clipboard, to paste into their password manager, it is available to any app. The user also copies the seed from the password manager into Trinity in order to verify that the seed was stored properly (or to add an old seed) during the onboarding process, and again the seed would be vulnerable here.
Trinity mitigates this threat by integrating Keepass2Android, an open-source password manager. As shown in this tutorial by Marcus Jang, users can securely save their seed in Keepass2Android and complete the verification process without ever copying the seed to the clipboard.
As mentioned in Threat 1, the Android clipboard can be accessed and modified by any app. If a user needs to copy and paste an address to which to send funds, a malicious app could detect that an IOTA address was copied to the clipboard, and then change the address to an attacker’s address. When the unsuspecting user pastes the address into Trinity, they will paste the attacker’s address and likely not verify it before sending funds.
To help ensure that the user is aware of this potential attack vector, Trinity will detect when an address is in the clipboard and the user presses the address field. When the user pastes it into the app to send a transaction, Trinity will alert the user that they should check the address and ensure it is correct. Also, in an attempt to make the process easier and to increase security, Trinity has incorporated the use of QR Codes for sending funds. Effective use of this feature will help to reduce the likelihood of this attack method.
Threat number 3 has been assessed as having a Low Risk rating, and only occurs on Android devices. This threat vector does not put the user, or their funds in any danger. In this threat, when the system date and time was manually changed, the user would be locked out of their account when trying to login.
This occurs due to a security feature inherent in the Trinity build, with its utilization of HTTPS for connecting to full nodes. HTTPS uses SSL for encryption of traffic, and if the system date is set outside of the SSL Certificate window, then the node would not allow external connections due to not meeting the criteria to maintain an HTTPS connection. This would deny people access to the wallet but not risk any funds.
To resolve this, the system time and date must be reset back to the current local time, at which point the Trinity wallet will be able to properly connect with full nodes and send data through encrypted channels using HTTPS. We are currently instituting a notification that warns the user that their date / time is incorrectly set.
Trinity supports deep linking (filling out transaction information from the contents of a web link) by registering itself as a handler of the “iota:” or “iota://” URI scheme. However, neither Android nor iOS make a URI scheme exclusive to a single app. In other words, multiple apps can handle the same URI scheme. Wang, et al explain this in more detail in their report on the security of deep links. If Trinity and another app (which also supports the IOTA URI scheme) are both installed on an Android device, when the user taps a deep link, they will be presented with a dialog asking which app to open (see here). A malicious app could disguise itself as Trinity so that the user is presented with two options that appear the same. If the user chooses the malicious app, it could potentially disguise itself as the genuine Trinity app and ask the user for sensitive information. The malicious app can then gain access to the user’s funds. On iOS, there is no definitive process for choosing which app will handle a URI scheme (see here).
To mitigate this risk, Trinity will disable deep linking for the time being until security features are implemented to confirm the authenticity of the app. This may include features such as security images, a common feature on bank websites.
A very early build of the desktop wallet was assessed, in which the seed generated on onboarding steps, was residing in the wallet’s state change history. This was therefore readable as plain text in the memory.
This threat was mitigated by:
- Updating onboarding seed storage to use the same (securely encrypted) vault that is used for persistent seed storage.
- Clearing the generated seed from memory when it is no longer needed for wallet setup.
We have been asked repeatedly about our implementation of biometric authentication in Trinity.
Biometric authentication is disabled on initial login as a security measure. Your seeds are stored behind two layers of encryption on your device; a decryption key is required to access them. Fingerprint/Face ID serve merely as a yes/no authentication request. This means that in order to have Fingerprint/Face ID on initial login, the seed decryption key would have to be stored on device. This presents a security risk. If your phone is stolen, and the decryption key is stored on your device, then it is possible for an attacker to extract your seed. However, in Trinity the decryption key is not stored on device. Instead it is generated from your password. While inconvenient, typing in your password on initial load greatly improves the security of your seed.
Biometric authentication is however available on subsequent logins within the same app session. After 5 minutes of inactivity, Trinity will log you out. You can then use fingerprint/Face ID to log back in. Unlike storing the seed permanently on device, this does not pose a security risk. The information required to generate the seed decryption key is wiped from memory when the app is reset or your device is restarted. To gain access to the decryption key, the attacker would first have to root/jailbreak the device, and in doing so, would wipe the decryption key from memory. This is one of the many reasons why we advise NEVER to use Trinity on a rooted/jailbroken device. It makes it far easier for an attacker to steal your seed.
I hope this helps to explain some of the design decisions we have taken in Trinity.
If you would like to discuss these mitigations or other features of the Trinity wallet, please join us on the #trinity channel of the IOTA Discord.