Thomas Roth

Most modern embedded devices have something to protect: Whether it's cryptographic keys for your bitcoins, the password to your WiFi, or the integrity of the engine-control unit code for your car. To protect these devices, vendors often utilise the latest processors with the newest security features: From read-out protections, crypto storage, secure-boot up to TrustZone-M on the latest ARM processors. In this talk, we break these features: We show how it is possible to bypass the security features of modern IoT/embedded processors using fault-injection attacks, including breaking TrustZone-M on the new ARMv8-M processors. We are also releasing and open-sourcing our entire soft- and hardware toolchain for doing so, making it possible to integrate fault-injection testing into the secure development lifecycle.

Modern devices, especially secure ones, often rely on the security of the underlying silicon: Read-out protection, secure-boot, JTAG locking, integrated crypto accelerators or advanced features such as TrustZone are just some of the features utilized by modern embedded devices. Processor vendors are keeping up with this demand by releasing new, secure processors every year. Often, device vendors place a significant trust into the security claims of the processors. In this talk, we look at using fault-injection attacks to bypass security features of modern processors, allowing us to defeat the latest chip security measures such as TrustZone-M on the new ARMv8 processors. After a quick introduction into the theory of glitching, we introduce our fully open-source FPGA platform for glitching: An FPGA-based glitcher with a fully open-source toolchain & hardware, making glitching accessible to a wider audience and significantly reducing the costs of getting started with it - going as far as being able to integrate glitch-testing into the Secure Development Lifecycle of a product. Then, we look at how to conduct glitching attacks on real-world targets, beyond academic environments, including how to prepare a device for glitching and how to find potential glitch targets. Afterwards, we demonstrate fault-injection vulnerabilities we found in modern, widely-used IoT/embedded processors and devices, allowing us to bypass security features integrated into the chip, such as: - Re-enabling locked JTAG - Bypassing a secure bootloader - Recovering symmetric crypto keys by glitching the AES implementation - Bypassing secure-boot - Fully bypassing TrustZone-M security features on some new ARMv8M processors We will also demonstrating how to bypass security features and how to break the reference secure bootloader of the Microchip SAM L11, one of the newest, TrustZone-M enabled ARM Cortex-M processors, using roughly $5 of equipment. After the talk, PCBs of our hardware platform will be given out to attendees.

In this presentation we will take a look at how to break the most popular cryptocurrency hardware wallets. We will uncover architectural, physical, hardware, software and firmware vulnerabilities we found including issues that could allow a malicious attacker to gain access to the funds of the wallet. The attacks that we perform against the hardware wallets range from breaking the proprietary bootloader protection, to breaking the web interfaces used to interact with wallets, up to physical attacks including glitching to bypass the security implemented in the IC of the wallet. Our broad look into several wallets demonstrates systemic and recurring issues. We provide some insight into what needs to change to build more resilient hardware wallets.

Hardware wallets are becoming increasingly popular and are used to store a significant percentage of the world’s cryptocurrency. Many traders, hedge funds, ICOs and blockchain projects store the entirety of their cryptocurrency on one or very few wallets. This means that users of hardware wallets store tens of millions of euros of cryptocurrency on small USB peripherals that costs only a few euros to manufacture. Moreover, many users that trade and speculate in cryptocurrency interact, update, and generate transactions using their hardware wallets on a daily basis. In this talk we look at the good, the bad and the ugly of hardware wallet security: We will walk through the different architectures of the wallets, look at the different attack vectors and talk about the challenges of building secure hardware before diving in deep finding vulnerabilities in the different wallets. The vulnerabilities we will present range from vulnerabilities that can be fixed in a firmware upgrade, to bugs that will require a new hardware revision, up to attacks on the microcontrollers themselves, requiring new silicon to be fixed. Some of the (most entertaining) vulnerabilities will be demonstrated live on stage.

Classes of Vulnerabilities we will look at

Firmware Vulnerabilities Firmware vulnerabilities are vulnerabilities affecting the software that runs on the hardware wallet. Since most wallets provide update mechanisms this class of bug can be patched in a future firmware release. Software Vulnerabilities Software vulnerabilities are vulnerabilities affecting the host software that runs on the PC or smartphone and communicates with the hardware wallet. Since most wallets provide update mechanisms this class of bug can be patched in a future release of the host software Hardware Vulnerabilities Hardware vulnerabilities are vulnerabilities affecting the device hardware of the hardware wallet. Hardware vulnerabilities are generally incorrectly set configurations of the hardware either during manufacturing or by the firmware. If the configuration is set by firmware these vulnerabilities can be patched in a future firmware release. Otherwise, they are unlikely to be fixed by the vendor. Physical Vulnerabilities Physical vulnerabilities are vulnerabilities affecting the hardware design of the hardware wallet. Once the device has been manufactured, hardware vulnerabilities cannot be mitigated and can only be fixed in a future hardware revision of the device. This class of vulnerabilities is unlikely to be fixed by the vendor. Architectural Vulnerabilities Architectural vulnerabilities are vulnerabilities affecting the overall architecture of the hardware wallet. These are inherent design flaws in the device and can only be fixed in a major hardware revision, i.e. a new version of the device. This class of vulnerabilities is unlikely to be fixed by the vendor.

Other people: Dmitry Nedospasov Josh Datko

Small gateways connect all kinds of fieldbusses to IP systems. This talk will look at the (in)security of those gateways, starting with simple vulnerabilities, and then deep diving into reverse-engineering the firmware and breaking the encryption of firmware upgrades. The found vulnerabilities will then be demonstrated live on a portable SCADA system.

Companies often utilize small gateway devices to connect the different field-busses used in industrial control systems (such as Modbus, RS232 etc) to TCP/IP networks. Under the hood, these devices are mostly comprised of ARM-based mini computers, running either custom, tiny operating systems or uClinux/Linux. The talk will look at the security aspects of these gateways by examining known and unfixed vulnerabilities like unchangeable default credentials, protocols that do not support authentication, and reverse engineering and breaking the encryption of firmware upgrades of certain gateways. The talk will consist of a theoretical part, an introduction on how to reverse-engineer and find vulnerabilities in a firmware-blob of unknown format, and a practical part, showcasing a live ICS environment that utilizes gateways, from both the IP and the field-bus side, to pivot through an industrial control system environment: Demonstrating how to potentially pivot from a station in the field up to the SCADA headquarters, permanently modifying the firmware of the gateways on the way.