Trinity: Threat Modelling Mitigation Report
The full article was originally published by Navin Ramachandran on Medium. Read the full article here.
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.
Threat 1: Attacker steals seed by monitoring the Android clipboard through a malicious app
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.
Threat 2: Attacker steals funds by manipulating receiving address copied to the Android 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 3: Changing Date/Time of the System prevents users from logging into the application. Application gets stuck at the Loading Screen.
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.
Threat 4: Attacker steals sensitive information using a phishing attack through a deep link
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.
Threat 5: Attacker obtains seeds by monitoring the Volatile Memory during new seed setup
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.
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.