Security and Trust in Open Source Security Tokens

Abstract

Using passwords for authentication has been proven vulnerable in countless security incidents. Hardware security tokens effectively prevent most password-related security issues and improve security indisputably. However, we would like to highlight that there are new threats from attackers with physical access which need to be discussed. Supply chain adversaries may manipulate devices on a large scale and install backdoors before they even reach end users. In evil maid scenarios, specific devices may even be attacked while already in use. Hence, we thoroughly investigate the security and trustworthiness of seven commercially available open source security tokens, including devices from the two market leaders: SoloKeys and Nitrokey. Unfortunately, we identify and practically verify significant vulnerabilities in all seven examined tokens. Some of them are based on severe, previously undiscovered, vulnerabilities of two major microcontrollers which are used at a large scale in various products. Our findings clearly emphasize the significant threat from supply chain and evil maid scenarios since the attacks are practical and only require moderate attacker efforts. Fortunately, we are able to describe software-based countermeasures as effective improvements to retrofit the examined devices. To improve the security and trustworthiness of future security tokens, we also derive important general design recommendations.

Unlock the Door to my Secrets, but don’t Forget to Glitch

“…In this work, we present the first in-depth analysis of the so-called flash erase suppression attack vector presented by Schink et al [SWUH21]. We improve and extend this work with an assessment of the potential risks caused by this attack on real-world products by investigating three open research questions:…”

“…The attack was carried out with voltage glitching on an 8-bit microcontroller. About 15 years later, Schink et al [SWUH21] present a similar attack, this time on a more recent 32-bit microcontroller and using EMFI. Although a long time has passed since this attack vector was first published, current microcontrollers still seem to be vulnerable.…”

“…Non-invasive physical attacks to bypass the debug interface protection have been shown for some devices of the nRF52 and EFM32 microcontroller families [SWUH21,Lim20a,Lim20b,Lim21]. The restrictions on their debug interface can be temporarily disabled by applying a voltage glitch or injecting a pulse via EMFI during the power-up phase of the microcontrollers.…”

“…Nevertheless, in some cases the effects are fully understood. In [SWUH21,BFP19], for example, an attack that reactivates a debug interface that was previously deactivated completely, was presented. This attack exploits a design flaw, which makes the microcontroller's hardware downgrade the protection level, if an error during the transfer of configuration data from flash memory into an internal register is detected.…”

SYNFI: Pre-Silicon Fault Analysis of an Open-Source Secure Element

“…Fault attacks are active, physical attacks that are commonly used to threaten the security of embedded devices [DM12, TM17, O'F20, ELG20] and secure elements [Hér,VWWM11,SWUH21]. In these attacks, a fault is induced into the chip causing several effects at the physical level, e.g., transient voltage and current changes as well as timing violations [RBSG21].…”