1.Internal analysis – DV
a. We believe that the modalities to avoid the cracking of the Google Wallet do not consist in addressing and managing the Rooting procedure, which is available to skilled consumers and therefore not safe, as it is approachable and executable at a retail level.
b. It is neither a matter of inhibiting access to Rooting or to other parallel / alternative procedures to Rooting, because each mode is vulnerable to cyber attack.
c. Regardless of the features of the terminal equipment or of the software offered by the manufacturer, the mobile operator (and/or the payments service provider) must be able to provide in autonomy, at a minimum, a locked bootloader, which anyway is not sufficient. The locked bootloader triggers a reset of the software with the consequent deletion of all data. Also this procedure would though not be sufficient for the following reasons:
– you can re-insert all the data previously erased by restoring the backup;
– not all devices have a locked bootloader;
– privilege escalation vulnerabilities allow a complete bypass of the locked bootloader.
d. We believe that the suggestions proposed by the engineer who discovered the vulnerability address the mitigation of the risk but other steps shall be taken.
e. We may consider two main categories of risk reduction.
As a first category it is fundamental, we believe, to work on:
(i) a logical distribution of the security features;
(ii) the fragmentation of the information of access to the monetary value (reported on credit card, or debit card or prepaid card, or other means);
(iii) the neo-morphic encryption algorithms. It is important to avoid that Google, or another system, asks and/or receives all the information related to the card/s, and to avoid those information to be stored on the web, instead of, for example, requiring part of the card’s information and requiring the insertion (subsequent and not contextual) of the other information of the card (available to the consumer only and at his discretion).
A second category to address consist, we deem, in the reduction of the risk level down to a single user or to a plurality of individual users, aggregated or not, but not to a large scale aggregated or not.
2. External analysis – Joshua Rubin (Zvelo Senior Engineer who discovered the vulnerability):
2.1 […]<<What is Rooting
official means, such as those provided by Google for their Nexus phones, and other times through software vulnerabilities that inadvertently allow “privilege escalation” (like the way that iOS must be “jailbroken”). The Digital Millennium Copyright Act (DMCA), as a case in point, had to have a special exemption added to it to allow rooting under “fair use.” While not illegal, the act of “rooting” is viewed by device manufacturers and carriers as taboo and they generally refuse to support or service “rooted” devices. Whether “rooting” by itself is a problem or not is debatable, however, the fact that much of the security of these devices currently depend on restricting users from the full power of the device is a significant weakness of the model>>[…]
2.2 […]<<Why Do Users “Root”?
With a “rooted” device, users can remove “bloatware,” install customized versions of the operating system, often referred to as “ROMs” (to improve performance and/or add new features) and even block advertisements. In the case of iOS, it enables users to install apps that are not approved by Apple (this is a native feature of Android).
Traditionally, the process of rooting a device begins with a user first unlocking the bootloader. Most, if not all, new phones and tablets today, even the Nexus line from Google, are shipped with a locked bootloader. This means that the device verifies the integrity and authenticity of the software loaded on the device, that it has come from the manufacturer, and that it has not been tampered with. When a device’s bootloader is locked, it cannot be permanently rooted and no custom firmware, or ROM, can be installed on the device.
Some devices, like the phones in Google’s Nexus line, have semi-official methods for unlocking the bootloader. By design, this process triggers a factory reset of the software on the device. The benefit of this is that any sensitive information available on the device before unlocking the bootloader will not be present after unlocking the bootloader.
Depending on the OS to reset the software upon unlocking the bootloader is in some ways effective, but still insufficient as a security model for the following reasons. First, users who choose to root their devices will likely just re-add the data that was there previously by restoring backups. Second, not all devices, especially older ones, have locked bootloaders and are not subject to this restriction. Third, privilege escalation vulnerabilities completely bypass this restriction and are ripe for exploit by malicious apps>>[…]
2.3 […]<<What Wallet Users Can Do Today
There are some steps that Google Wallet users can take today to help mitigate the risk of this vulnerability.
- Do Not “Root” the Cell Phone – Doing so will be one less step for a thief.
- Enable Lock Screens – “Face Unlock,” “Pattern,” “PIN” and “Password” all increase physical security to the device. “Slide,” however, does not.
- Disable USB Debugging – When enabled, the data on mobile devices can be accessed without first passing a lock screen challenge unless Full Disk Encryption is also enabled.
- Enable Full Disk Encryption – This will prevent even USB Debugging from bypassing the lock screen.
- Maintain Device Up-To-Date – Ensure the device is current with the latest official software. Unfortunately, users are largely at the behest of their carrier and cell phone manufacturer for this. Using only official software and keeping devices up-to-date is the best way to minimize vulnerabilities and increase security overall>>[…]
End of the document
Questions from the future is a communication from Dalla Vedova law firm aiming to address current issues in the infrastructure, TMT, Media, IT and Payment Services sectors, as well as the bundling of the same.
The scope is to induce operators and investors to show a different attention to topics originating from the market, litigation or regulatory interpretation and consider taking action, customarily via a feasibility project. We shall be glad to assist if requested.
Contact: Avv. Marco Dalla Vedova
DALLA VEDOVA Studio Legale
Associazione Professionale
Via Vittorio Bachelet n. 12 │00185 Roma │ITALIA T +39 06 4440821 │F +39 06 4462165 Email: mdv@dallavedova.com │ Email certificata: mdv@pec.it http://www.dallavedova.com
Copyright Notice Unless otherwise noted, this publication and all material contained in it is owned and controlled by DALLA VEDOVA Studio Legale. All rights are reserved. Please contact us if you want to publish, or make any commercial or public use of the publication or any of the material contained in it. This publication is intended to provide general information only and should not be relied upon as giving legal advice. For legal advice on a specific issue, please contact one of the lawyers at DALLA VEDOVA Studio Legale.