A Brief Overview
Electronic multi-card technologies are a nice idea; load all of your payment and membership cards on to a single credit-card sized device which reduces the number of cards you need to carry around in your wallet or purse. However, many of these technologies have struggled to make it into production. The Fuze Card is one of the few that have successfully made it to market, with the chip-less version of their cards arriving to backers toward the end of 2017 after being successfully crowd-funded on the Indiegogo website; but what is the security of this device like?
The following article takes a brief look at the security claims made by the vendor of the Fuze card, and discusses security concerns that were identified with the device regarding the security of the stored card information. A critical security vulnerability was also discovered with the Fuze card that allowed the theft of all card data on the device, and was disclosed to the vendor in January 2018.
Update 29-Apr-18: The vendor has now implemented security features to address the discovered issues in their latest firmware. Further information can be found in the “Vendor Notification and Response” section below, and in this article.
What is the Fuze Card?
The Fuze Card is a credit-card sized device developed by BrilliantTS that is designed to store a number of payment and membership cards, allowing the stored cards to be selected and used, and removing the need to carry around multiple cards. To add a payment card to the device, the user reads the original card information using the eCard Manager mobile application and a provided card reader. The data is then sent to the Fuze Card via a paired Bluetooth Low Energy (BLE) connection.
Production of the Fuze Card was crowd-funded, being one of the highest funded Indiegogo projects of 2017, gaining over fifteen thousand backers, and raising over two million US dollars. Two versions of the card were promised during the campaign, an EMV chip card and a chip-less version. So far only the chip-less version is available, which allows only magnetic stripe functionality for payment cards and is the subject of this review.
Upon receiving a chip-less version of the Fuze card, it’s functionality was exercised. Loading payment and membership cards to the device using the eCard Manager application and the supplied card reader was a fairly simple process, and payments were successfully made using the magnetic stripe without any issues. Examples of the loading process and a Fuze card being used may be found on the vendor’s YouTube channel, and images of the received card can be seen below for reference.
An Interesting Observation: When attempting to make a swipe payment using a chip and pin card that has been added to the Fuze Card, a Point of Sale (POS) machine will likely fail and prompt to insert the chip. However, at least with my experience in Australia, it’s possible to cause the POS to fall back to a swipe payment by making three failed attempts with the chip reader. It’s interesting that a fall back to a less secure form of payment is possible.
Features of the Fuze Card include:
- Has an ePaper display to show card information and barcodes
- Has an electronic magnetic stripe to allow swipe payments with payment cards
- Uses a mobile application to manage the Fuze Card
- Uses BLE to communicate with the mobile application and transfer card data to the Fuze Card
From a security perspective this sounded like an interesting target. There was sensitive information to gain, such as credit-card details, and quite a bit of possible attack surface through the mobile application, the user’s mobile device, BLE, and physical access to the Fuze Card itself. So what did the Fuze Card offer as far as security features and the protection of that information?
Security Claims and Features
Reviewing the Fuze Card website, the vendor claimed the following regarding the security of the device:
The main security features of the Fuze Card were BLE Passkey, security level 2 (requires BLE connection to user’s mobile), data blind, passcode, and card lock, which are detailed in the following table:
|BLE Passkey||BLE pairing with the Fuze Card requires entering a six digit pin that is displayed on the Fuze Card’s ePaper display. This is to prevent pairing with the card without physical access.|
|Security Levels||There are three security levels that may be applied to the Fuze Card from the eCard Manager application. Level 1 is default and implements no additional security. Level 2 enables lost tracking and requires the card to be connected to the user’s mobile device to make payments, otherwise the card is locked displaying the connect screen as shown in the image. Level 3 was not yet implemented, however appears to enable lost alerts.|
|Data Blind||When data blind is enabled, some card information is obscured by asterisks on the Fuze Card’s ePaper display.|
|Passcode/Tapcode||When passcode is enabled, the user is prompted to enter their passcode of six presses of the Fuze Card’s buttons when powering on the card.|
|Card Lock||When the Fuze Card is used with an account that it’s not registered with, the eCard Manager application locks the card with the screen shown.|
Although there appeared to be a number of security features, how well did these protect the security of the information on the device? In the push to deliver the product on time to the backers, was security of the device overlooked? We’ll take a look in the following sections, starting with some of the methods used to review the security of the Fuze Card.
To review the security aspects of the card, the Android eCard Manager application code, along with the communication between the application, eCard Manager servers, and Fuze card were investigated. Several versions of Fuze card firmware binary images were also able to be retrieved, however they were encrypted and not investigated as part of the review.
APK De-compilation and Code Review
An Android 7.1.2 mobile device was utilised to download the eCard Manager application (Version 1.0.8), as seen below, from the Google Play Store, and the Android Debug Bridge (ADB) toolkit was used to pull the Android Application Package (APK) from the mobile device.
The APK is just an archive file, however many of the files within are encoded along with the application code being compiled as a Dalvik Executable (.dex). Tools such as
apktool can decode these files and de-compile the Dex file to smali bytecode, which is useful if wanting to patch and re-compile the application. However, for this review the open-source
jadx Dex to Java de-compiler was utilised to return the code to a sufficiently readable Java format. De-compilation of the code was not perfect and was also found to be obfuscated, however it was still quite readable for the most part.
HTTP man-in-the-middle (MitM) was utilised to view communication between the eCard Manager application and the eCard Manager servers. This was achieved by providing a wireless access point (AP) to the mobile device, and configuring it’s proxy settings so the eCard Manager application’s web traffic would pass via an intercepting proxy.
An example of the traffic can be seen in the figure below, where the type and name of payment cards stored on the Fuze Card are sent to the eCard Manager servers.
BLE traffic is not as easy to sniff due to it’s encryption and frequency hopping, however tools such as the BtleJuice Framework and GATTacker are able to achieve this when the BLE device uses the simplest “Just Works” pairing method. This is due to the “Just Works” method using a set Temporary Key (TK) of 0 during the pairing process and does not verfiy the devices taking part in the connection. In the case of the Fuze Card, it used the “Passkey” method of pairing where a six digit number is generated by the card and displayed on the ePaper display for the user to manually enter on the mobile device, which is then used as the TK. The previously mentioned tools are unable to be utilised for this pairing method. CrackLE is another tool that has the ability to crack and decrypt BLE traffic, however it requires sniffing the initial pairing process with a quality capture.
As we were in control of the mobile device, there was a much simpler method to view the BLE traffic. Within the “Developer options” of the Android phone, there’s an option to log Bluetooth traffic called “Enable Bluetooth HCI snoop log”. Turning this option on begins logging all Bluetooth traffic to a file on the device named
btsnoop_hci.log. The file can then be pulled using ADB and viewed in Wireshark.
An example of the captured btsnoop traffic can be seen in the figure below, which shows payment card data being synchronised between the Fuze Card and the eCard Manager application.
To explain the figure above a little better, the eCard Manager application (localhost) sends a write request (No. 406) to the Fuze Card (Brillian_00:46:79) to request the information of a payment card. In response, the Fuze Card notifies the application with the card information split across multiple packets (No. 409-412). The last packet is selected, which shows the card type (VISA) in plain-text as part of the returned value.
An Interesting Fact: Hedy Lamarr, an inventor and famous actress, was one of the first to pioneer spread spectrum frequency hopping technology and her principles contributed to the Bluetooth technology in many of the devices we use today.
Although the review of the application code and Fuze Card was not extensive, there were some considerable security concerns found in protecting sensitive information such as payment card details. The main issues are detailed below.
Logging of Sensitive Information
Reviewing the code it was noticed that the eCard Manager appeared to be logging sensitive information such as authentication details and session tokens, along with all card information. In fact, every time the application and Fuze Card were connected and synchronised, all stored card information was sent back to the application, which was then logged in plain-text to the Android log. This can be seen in the figure below, in which the
logcat utility is used to view the log file.
Although bad practice, this is not necessarily a major security issue as Android versions 4.1 and above remove the ability for user applications to view the logs. However, prior versions would allow applications to request the READ_LOGS permission, giving the potential for malware on those devices to scrape the log file for this information.
Application Authentication Bypass
As previously mentioned, much of the Fuze Card is controlled via the eCard Manager application. The application requires the creation of an account and authentication prior to being able to pair a Fuze Card, as can be seen in the image below.
Once logged in and paired for the first time, the Bluetooth address of the Fuze Card is associated with that account and the user is free to add cards and modify the Fuze Card settings. In addition to this, any attempt to use a Fuze Card that is associated with another account locks and potentially wipes the Fuze Card, with a notification email being sent to the registered email account warning of the attempt.
The issue here is that as a privileged user on the Android phone, any arbitrary application activity may be started out of the usual order. This means that even with a clean install of the application, no WiFi access, and no account, the authentication may be bypassed to pair with any Fuze Card, allowing access to it’s stored card information and control of it’s security settings. This may be achieved by using ADB and the activity manager (
am) as shown in the figure below.
Note: The application will unlikely continue after pairing the Fuze card during the ManualScanActivity due to waiting for server response, however the CardSyncActivity can then be started to force synchronisation of data with the card, after which the application works relatively as normal.
This still requires pairing with the Fuze Card and hence at least momentary physical access to view the BLE passkey, however this bypasses all other security controls giving complete control of the Fuze Card, and the added benefit of never notifying the owner or risking the Fuze Card being locked and wiped.
Trust in the Connecting Device
Given the ability to use the Fuze Card without an authenticated user, and the lack of encryption of data other than that given by BLE, there appeared to be no verification of the user by the Fuze Card, and complete trust of the connecting device once paired. This means that is must be possible to directly connect to the Fuze Card and interact with the provided BLE services.
Interacting With BLE Services
To interact with the BLE services of the Fuze Card, the tools provided by the BlueZ Linux protocol stack were used; specifically
bluetoothctl tool was used to pair with the Fuze Card and identify the advertised services and their GATT characteristics, as can be seen in the figure below.
Through analysis of the btsnoop_hci.log and code review, it was determined that the service UUID of
0000ff01-0000-1000-8000-00805f9b34fb was the main service used when interacting with the Fuze Card. This service has one
write characteristic, used to request information from or write to the Fuze Card, and another
notify characteristic, which responds by notifying the connected device of value changes. These flags can be seen in the figure below.
In the case of the Fuze Card, a value is written to the
write characteristic, for instance to turn off a security feature, and the Fuze Card responds with a value indicating success or failure using the
notify characteristic. An example of a value that would be sent to the Fuze Card to disable the data blind security feature can be seen in the following btsnoop_hci.log capture.
A quick breakdown of the data structure can be seen below, with var being the variable or function being interacted with, the total and current packet numbers, and the value in ASCII to be written, in this case ‘1’.
Note: The first byte was always
0x02 for write requests, and
0xdd for notification responses. The last byte of the write data is a checksum value, however it was discovered that this value was not verified and could be made any value.
gatttool it was possible to directly write these values to the paired Fuze Card and observe the response, as can be seen in the figure below which writes the value to disable the data blind feature and listens for the response.
0x90 in the notification response indicates success, with
0xff in the same position indicating failure of the request.
Observing the Fuze Card during this attempt showed that the data blind feature was successfully disabled, as can be seen in the figure below.
Using the same method, it was possible to determine the structure of card information stored on the Fuze Card, and retrieve arbitrary card information as shown below where the details of the first stored payment card is retrieved.
The issue with allowing this is that anyone with momentary physical access to pair with the Fuze Card may retrieve payment card information, bypassing all other security controls, and avoiding alerting the owner other than them potentially noticing they have been unpaired from their card. In addition to the previous issue, malware on the connected mobile device may also have the ability collect this information from a legitimately paired Fuze Card.
Proof of Concept
Knowing that it’s possible to directly control and retrieve data from a Fuze Card, a Proof of Concept (PoC) tool was created that allows retrieval of all stored card information from a Fuze Card without disturbing enabled security features, or optionally disabling the security features to allow full use of the card. This is available from the elttam GitHub repository, and is shown in the figure below.
Note: After disabling security features using the PoC, it may be necessary to power the Fuze Card off and on again before they disappear.
Revisiting Security Claims
After reviewing the security of the Fuze Card, the claims made by the vendor were revisited to determine if they were accurate. Let’s take a look at them in turn.
During the review it was not determined if the payment card information was stored within an AES 256 encrypted chip, however card information was not encrypted during transit except for that being provided by BLE. It’s not entirely true that card information isn’t sent to the servers either; both the type (i.e. VISA) of all payment cards along with what the user named them is sent to the eCard Manager servers, as can be seen in Figure-3. It would be recommended to notify Fuze Card users of exactly what card information is stored by the servers. In addition, all card information is logged by the application so it at least resides in memory, however card information did not appear to be permanently stored on the mobile device.
As seen above, features such as location tracking and remote lock/wipe are implemented by the eCard Manager application, hence will not be activated by an attacker that is bypassing authentication or directly interacting with the card via BLE. All of these extra security features have been shown to be easily bypassable and offered no additional security.
As stated above, these activities were not instant and rely on someone attempting to connect with the Fuze Card via the eCard Manager application before any remote wipe is initiated.
This did not appear true in regular use. With the level 2 security feature enabled, the Fuze Card did indeed lock when it lost the BLE connection, however when the card hold function was used, it was possible to turn off the card hold function to make payments with any stored card when outside of Bluetooth range.
Lastly, lost alerts appear to be a part of the level 3 security feature which was not implemented in the reviewed software version.
Vendor Notification and Response
The Fuze Card vendor BrilliantTS was notified of the above issues in January 2018, and given a 90-day responsible disclosure period. They were slow to respond to the disclosure, however have since worked to address the issues and release a new version of the mobile application and Fuze card firmware, a notice of which can be found here.
Update 29-Apr-18: Fuze have now implemented a security feature where BLE is not activated until the passcode is successfully entered on the card. In doing so, an unauthorized third party should not be able to access the card via BLE in the scenario the card is lost or misplaced, unless they can bypass the passcode feature. In addition, Fuze have implemented a feature where all loaded cards are deleted if the passcode is entered incorrectly five consecutive times, increasing the difficulty of this type of attack. Both of these features have been implemented and are currently active in the latest firmware detailed here.
The main security issue was also independently discovered by researcher Mike Ryan, which he publicly disclosed in April 2018, and can be found here. This sparked numerous news articles on the vulnerability, including articles in Forbes and arsTECHNICA.
The following details the disclosure timeline:
- 29-Dec-17 - Initial contact with BrilliantTS notifying of security research and requesting a security contact
- 03-Jan-18 - BrilliantTS responded with a security contact
- 21-Jan-18 - Disclosure of found security issues to BrilliantTS and offer/start of a 90-day responsible disclosure period
- 02-Feb-18 - Response from BrilliantTS stating it has been referred to their development team
- 14-Feb-18 - Official response from BrilliantTS stating they are addressing the issues disclosed with an updated version anticipated for release in early Q2 2018
- 04-Apr-18 - Mike Ryan publicly discloses the vulnerability via the ICE9 blog with CVE-2018-9119
- 05-Apr-18 - BrilliantTS releases a public notice regarding the security issues
- 07-Apr-18 - Contacted by reporter Thomas Fox-Brewster from Forbes regarding my disclosure after he contacted BrilliantTS regarding Mike Ryan’s blog post, in which he released a news article on the issue
- 21-Apr-18 - End of 90-day responsible disclosure period
After reviewing the security of the Fuze card and the related eCard Manager Android application, the security claims made by BrilliantTS were not accurate. A number of best practice security issues were identified, along with a critical vulnerability that could be used to disclose all card information on the device. This was disclosed to the vendor and they have since been addressing the issues with updates to the application and Fuze card firmware.
Taking into account that the identified security issues are being addressed, is this card any better than carrying individual cards in a wallet? When it comes to convenience, definitely. As far as security, using this card does add some additional vectors for attack that BrilliantTS will need to be wary of and active in addressing; such as BLE, the mobile application, and their online services. The risk posed to the user appears similar to someone losing their wallet, which is unlikely to be any large financial loss. However, a new venture by BrilliantTS called FuzeX which allows cryptocurrencies to be used with a similar device, has potential to pose a lot more risk of large financial loss and is much more attractive to an attacker. This was also communicated to BrilliantTS, and I hope they continue to be vigilant and active regarding the security of their devices.