BC Vault One button side channel

In May 2019, I discovered that the BC Vault One has different electrical noise emissions depending on the physical pressure on the device case. This can potentially be used by a local hardware implant in USB periphery to capture information during the secret PIN entry, as I will explain in this article.

The effect was found during the disclosure of another side channel where a similar attack could read meaningful information off the screen based on electrical characteristics of the USB power line. Side note: for the BC Vault, the practical security impact of the OLED issue was fairly minor since barely any confidential information is displayed on the screen.

Consulting

I’m a freelance Security Consultant and currently available for new projects. If you are looking for assistance to secure your projects or organization, contact me.

The hardware side channel

The BC Vault One has a number of electrical signals in a relatively low frequency range (0MHz - 1.5MHz) that shift in frequency when pressure is applied to particular areas of the device case. This effect is present during normal operation of an unmodified device connected to a regular host computer and has been observed experimentally in two ways:

1. H-field probe + low noise amplifier + software defined radio
2. resistor shunt in the USB power line + software defined radio

Technical references: probe, LNA, SDR

Notably, the effect

• is not caused by the hardware buttons circuitry
• is present with a high signal/noise ratio when the display is off (automatic screensaver mode)
• is strongest around the upper right display corner
• varies in strength depending on the force and specific positions on the case
• is strongly linked to the flexure of the PCB

Here is a combined recording of the behavior of pressure applied next to the buttons:

For the actual “Please enter PIN” dialog with active display and button input, the amount of noise is significantly higher, but the frequency shift is still observable at several frequencies.

Here is an annotated recording of the FFT waterfall diagram with markings for the four strong button presses under practical conditions:

Due to the source of the side channel, other physical interactions with the device also cause frequency shifts. An attacker would likely combine other signals (display, device activity after button entry, …) to find out when buttons are pressed and use known inputs (right arrow + enter to confirm, …) to calibrate the classification and make the detection more robust.

After disassembling the device, I looked at four particular components to figure out where the frequency change is coming from:

• blue: the main ATSAM4SD32B microcontroller in blue (U1, spec)
• red: the fast 12.000 MHz oscillator (Y1)
• green: the slow 32.768 kHz oscillator (Y2)
• orange: the MB85RQ4ML SPI FRAM storage (U2, datasheet)

At first, I suspected that the flexure of the PCB causes the change in frequency through physical effects on one of the discrete oscillators, but my measurements have not confirmed this. When sweeping the PCB with the H-field probe, the signal is strongest around the storage chip, so perhaps an internal clock or a nearby component are responsible.

At the time of publication of this article, the side channel is still present with the newest firmware 1.3.7 from February 13, 2020.

I am not aware of any mitigations introduced by the vendor.

Security considerations

A few words on why this research is relevant in my opinion, even though this class of side channels does not have the same impact as for example a firmware vulnerability.

The design of most hardware wallets is aimed at offloading sensitive computations and decisions off the potentially compromised host computer while staying relatively small, simple and affordable. For this reason, wallets mostly come with a small screen and physical inputs to have a trusted input and output channel directly to the user. The goal is to rule out malicious actions by malware on the host computer (like manipulation of transactions and transaction summaries before sending) and to prevent confidential information like the PIN sequence or displayed secrets to be obtained by attackers.

This confidentiality has obvious limits if other people or cameras are present. However, side channels can undermine the security goal of confidentiality in ways that are not easily anticipated by the vendor or the end user. In this sense, the secrets leaked via side channels become a problem, particularly if they can be obtained by hidden equipment (like an USB cable similar to the O.MG cable, for example) that the user cannot easily avoid or discover.

It should be kept in mind that hardware wallet device security is often multi-layered for good reasons. An attacker might need to collect multiple secrets obtained from the user (PIN, passphrase, …) and have physical access to the device to steal funds, which makes the attack costly and hard to scale. Consequently, the practical impact of this side channel in a “regular use at home & small amount of saved funds” scenario is likely small, particularly if the presence of manipulated peripherals or physical access can be ruled out. For high-value targets, this may be different.

Disclosure process

As mentioned previously, I discovered the BC Vault One specific button side channel while researching and disclosing the OLED side channel which affected multiple vendors. I requested & received a test unit from REAL Security in mid-May and reported the button issue and relevant FFT plot to them in late May.

They quickly acknowledged the report but indicated that they only considered RF side channels at larger distances as a security problem.

In late July, I inquired for the REAL Security’s status with regards to potential fixes to determine the disclosure progress and establish a reasonable date for publication. They responded that they could not find any significant RF emissions and still did not consider local, USB cable-based attacks an issue.
Then they started demanding control over my reporting of the vulnerability.

At first, they included a particular text paragraph and demanded

The following information must be included verbatim: [...]

After rejection of this demand, they changed to

Feel free to rewrite that in your own words in any other way as we wrote it and confirm it with us

I’m very much in favor of open discussions of issues, aspects, interpretations and security implications with the vendor during the disclosure process. While I might not agree with individual technical points made during an argument and decide not to include them in my descriptions of the issue, it is still useful to have these discussions early to learn more about the assessment and perspective of the other party. I understand that vendors have a different set of goals and priorities that drive their reporting, for example about the level of detail that is presented to the public in an advisory.

However, the coordinated disclosure process does not give vendors the right to control what the other parties do or publish after the disclosure period is over. By repeatedly claiming that they had such a right despite my refusal, REAL Security undermined the mutual trust that a coordinated disclosure is based on, and I let them know as much. Unfortunately, they still continued this behavior, privately misconstrued my previous behavior with other vendors, refused to change their position and continually argued that strong demands of this sort are justified.

After several days, I gave them a final chance to apologize and clear up the misunderstanding, but they instead declared that the exchange was over.

I have not heard from them since.

Relevant product

product	analyzed firmware	analyzed hardware	vendor references
REAL Security BC Vault One	1.3.7 and earlier	V1.2	-

Detailed timeline

See the OLED side channel article for related events of the larger OLED issue disclosure.

Date	info
2019-05-08	Initial contact with REAL Security for OLED disclosure
2019-05-16	Test unit arrives
2019-05-26	Report on button side channel issue
2019-05-27	Vendor acknowledges receipt of the report
2019-05-27	Answer to vendor question
2019-07-27	Inquiry to vendor about issue status
2019-07-27	Vendor answers questions
2019-07-30	Answer to question about RF aspects
2019-07-30	Reply by vendor, vendor demands to control reporting
2019-07-30	First refusal to vendor demands
2019-07-30	Vendor misconstrued previous disclosure behavior
2019-08-06	Vendor reaffirms demands
2019-08-12	Vendor asks for more information on button side channel
2019-08-13	Request to vendor for clarification of their previous behavior
2019-08-13	Vendor again argues for their right to make demands
2019-08-14	Reply to vendor with strong refusal
2019-08-14	Vendor aborts communication

Bug bounty

I have not received a bug bounty for this issue.