 Hello and welcome to our presentation about security and trust of open source security tokens. My name is Marc Schenk and I did this research together with Alexander Wagner, Fluchen Unterstein and Johann Heisel. Let us start with a short motivation why passwords are bad and why we need additional security measures. Passwords are the most common means of authentication but they come with a lot of problems and so it's not surprising that most hacking related data breaches are the result of weak or stolen passwords. To illustrate only a few problems of using passwords, let us use the Twitter account of this guy as a case example. The Twitter account of the former president Donald Trump was hacked at least twice. In 2016 his account was hacked by a Dutch group of hackers. They found his password on a database that was part of a data breach on LinkedIn in 2012. Trump used the same password for LinkedIn and Twitter. His password back then was uofiled which is obviously a weak password. Then in 2020 his account was hacked again by one of the Dutch hackers. This time he spotted a Twitter post that shows the guest Wi-Fi password used on the 2020 election rally for Donald Trump. After trying some variations of this password he got access to Trump's Twitter account. This time Trump's password was MAGA2020 exclamation mark. Not as bad as the first one but still easy to guess. But maybe Trump was relying on the expertise of Kaspersky. According to their password checker this password is nice and hack resistant. But seriously this shows another problem with passwords. In some cases the context to who uses a password influences the security level. To add these and a bunch of other password related problems you should use hardware security tokens. Hardware security tokens are dedicated devices that you usually plug into the USB port of your computer. Instead of guessable passwords or passwords with questionable entropy, security tokens use strong cryptographic algorithms for the authentication. The downside is however that end users have no control and inside what's happening. You have to fully trust the heart and software of the token. To gain the user's trust some manufacturers make their products open source. This gives insight and detailed information about how these devices work and allow security audits by independent researchers and other third parties. Nevertheless potential physical attacks for example during the whole supply chain until the device reaches the customer still remain. So our research question was how secure and trustworthy are these devices? Is it possible to manipulate or clone these devices without being noticed by the user? Before we answer this question and move on to the results of our security analysis it is important to specify an adversary model that is suitable for hardware security tokens. Once we are able to reach the goal within the rules of this framework our attack is considered to be successful. Our goal is always to gain unrestricted access to all the services a token is used for. For example a service like Google or GitHub. We can achieve this goal in two ways. First we can extract the cryptographic keys directly from the token to clone it. Second we can manipulate the token's firmware such that for example the generated keys used for the authentication are weak and boot forcible. Since we are interested in unrestricted access to the services we are not allowed to leave any evidence of our attack. For example our longer disappearance or even permanent theft of the token would alert the user. The user could revoke the token from all registered services which would make the attack pointless. The attack equipment is restricted to low-cost devices that sum up to an amount of a few thousand US dollars. The equipment should also be portable such that it can be used in an evil maid scenario for example. For this adversary model we consider two attack scenarios evil maid and supply chain attacks. For example an evil maid attack is when the room service compromises your token while it is unattended in your hotel room. This is far from being a theoretical threat. We have seen similar cases where attackers broke into a hotel room and compromised the laptop of a professional online poker player. The supply chain scenario covers all attacks that can be carried out in a way from the producer to the end customer. This also covers scenarios where an attacker offers fake tokens with manipulated firmware. We have already seen such attacks in the past for example network devices have been intercepted and manipulated on the way to the customers. There are also cases where manipulated network devices were sold directly. In both scenarios an attacker has physical access to the token but is limited in time. For example a few minutes in hotel room or maybe half an hour during an attack somewhere in the supply chain. In our research we evaluated all commercially available open source security tokens. In total we analyzed seven security tokens and identified several vulnerabilities that can all be carried out in a supply chain or evil maid scenario. Our methods range from simple bus probing to more sophisticated fault injection attacks. In this presentation I will show you three different attacks. One bus probing attack on the NitroKey FIDO U2F and a side channel and fault injection attack against the ZOLO from ZOLO keys. This selection is intended to illustrate you the different types of attacks that can be carried out on hardware security tokens in a supply chain or evil maid attack scenario. For all other attacks and vulnerabilities we identified I would like to refer you to our paper. Let's start with the first device the NitroKey FIDO U2F. This device consists of a microcontroller and a secure element as highlighted on the right-hand side. The secure element is used as key storage and to perform the cryptographic algorithms. The microcontroller on the other hand implements the authentication protocol and USB communication. It is important to note that a secure element contains a hardware registration key. This is specified by the FIDO standard and can be used to verify the authenticity of the device. To prevent an attacker from simply exchanging the secure element or manipulate the firmware of the microcontroller both chips contain shared secrets. However, we identified a flaw that allows us to recover the shared secrets via probing the I2C bus between microcontroller and secure element. With that, we are able to manipulate the firmware on the microcontroller and implement malicious features like a backdoor or a key generator with low entropy. Let's take a look at what happens on the I2C bus when we register the NitroKey FIDO U2F on an arbitrary service like Google or GitHub. The protocol consists of multiple steps but only the first two are important for this attack. In the first step, a NUNS and the application ID are concatenated and then transferred from the microcontroller to the secure element. The FID identifies the service, for example, Google, and the NUNS is generated on the microcontroller. Both variables are not important to understand this attack. On the secure element an HMAG is generated and the result is then transferred back to the microcontroller. Afterwards the HMAG is used to derive the service key. For that, one of the two shared secrets, the R key, is used. In this figure, the shared secrets we are interested in are highlighted in boldface. In the next step, the service key is concatenated with the second shared secret, the W key, and then transferred to the secure element. Both are fed into a hash function and the result is then transferred back to the microcontroller. The MAC is then used in a later protocol step which is not important for this attack. The problem of the protocol is now quite obvious. The service key and the second shared secret, W key, are transferred in plane on the bus. Together with the HMAG from the previous step we can easily infer the R key. Now we have the secrets shared between the secure element and the microcontroller. For that, we only had to capture two messages on the I2C bus, here highlighted in red. With the two secrets, we are now able to replace the firmware on the microcontroller and implement malicious features. This attack can be mounted in a supply chain and evil maid scenario. For example, a key generator that produces guessable service keys. What makes this attack so malicious is that it scales well in a supply chain scenario and the device remains authentic. The user is not able to identify the manipulation which fully undermines the trustworthiness of these devices. The reason is that with both shared secrets or malicious firmware can still use the secure element with the original hardware the station key. This would not be possible by simply exchanging the microcontroller. This vulnerability can easily be fixed by moving the MAC calculation to the microcontroller instead of outsourcing it to the secure element and thereby expose sensitive information on the I2C bus. Unfortunately, the manufacturer did not provide a patch for the firmware so far. However, since the firmware's open source our results enable third parties to fix the vulnerability. The next attack I'm going to present you is a side-channel attack that affects the ZOLO from ZOLO keys and all devices that are based on it. The ZOLO consists only for microcontroller the STM32L4. This microcontroller contains all the cryptographic credentials for the authentication on the service. Deleted curve algorithms are implemented in software using the microECC library. We identified a timing side-channel in the ECDSA implementation of the microECC library. To be precise the scalar multiplication of the random number k and the base point g. In the following I'm going to show you an oracle based single trace attack on this ECDSA implementation. The oracle device is just another STM32L4 microcontroller with a modified version of the microECC library. For this attack a large EM probe with a diameter of about one centimeter placed directly on the top of the microcontroller is sufficient. You can see the placement on the right hand side. Actually it's not even necessary to remove the token casing. In the following example we are going to extract the hardware the station key from a ZOLO security token. All other credentials like service keys can be extracted in the same way. The attack works as follows. Once we have physical access to the token for example when the token is left unattended in a hotel room we trigger a registration on an arbitrary service. This starts the ECDSA operation with the hardware the station key. During this process we capture the electromagnetic emission of the microcontroller. After that the attack phase is already over and we do not need physical access to the token any longer. The figure shows the electromagnetic emission of the attack token by processing the first bit of the unknown random number k. Now we use our oracle device where we have full control over the variable k. To recover the first bit of k from the captured EM trace we capture two EM traces of our oracle device with the first bit of k set to 0 and 1. You can see these traces on the top and bottom of the figure. Finally we visually compare the EM trace of the attack token with the traces of our oracle device. When we highlight certain parts of the EM traces you can see that the EM trace of the oracle with k equals 1 matches the token's EM trace. On the other hand the EM trace of the oracle with k equals 0 shows clear differences. This means that the first bit of k of the attack token is 1. To recover the second bit we set the first bit of k of the oracle to 1 and repeat the procedure. This approach can be repeated until every bit of k is recovered. Okay how does this side channel attack affect the security and trustworthiness of the solo key security token? This attack allows to extract the hardware station key as well as all other service keys from a security token. With the hardware station key it is possible to distribute authentic but malicious token. You as a customer cannot distinguish this token from the original one. The token's manipulated firmware could for example generate guessable service keys that can be brewed first later. This attack allows also to fully clone a token and gives an adversary unlimited access to all services for which a token is used. Even though the key recovery phase takes some time this attack can be easily mounted in a supply chain in an evil maid scenario. The attack phase is very short, only a single EM trace per key needs to be captured which can be done in a few minutes. Fortunately the side channel leakage can easily be mitigated by randomizing the base point G in the ECDSA implementation. We reported the vulnerability in the most reasoned version of the micro-ECC libraries already fixed. The side channel attack I showed you has one major drawback. It allows us to extract only keys that are already registered on a service at the time of the attack. To circumvent this limitation we need access to the service root key. With this key we can derive the keys for all services even though they are not used at the time of our attack. This brings us to the last and my favorite attack of this presentation. This time we target the tokens hardware, more precisely the readout protection of the SCM32L4 microcontroller. Once this protection is broken we have access to the root key via the microcontroller's debug interface. To achieve this we use a side channel assisted fault injection attack. We choose electromagnetic fault injection to leave no traces on the device. On the right hand side you can see the position we used for the EM side channel probe and the EMFI injection coil. Before I show you how the attack works let's start with a brief overview of the SCM32L4 readout protection. The readout protection is responsible to prevent malicious readouts via the debug interface. The readout protection has three different levels. In level 0 used for firmware development there is no protection and all components of the microcontroller are accessible via the debug interface. In level 1 access to the flash memory is restricted but the SRAM remains accessible. The highest level level 2 fully disables the debug interface. According to the manufacturer this level is irreversible. In a few minutes you will see that this is not quite right. To understand how the attack works we first need to understand how the RDP level is implemented. The RDP level is part of the option bytes which are permanently stored in flash memory. During the boot phase the option bytes are transferred from flash memory into shadow registers. To detect errors during this transfer the actual option bytes and their complementary values are transferred. The important point here is that once an error is detected fallback values are used for the option bytes. Interestingly the fallback state for the RDP level is not 2 the most secure one but level 1 where the SRAM is accessible. Okay so our attack idea is to disrupt the memory transfer of the option bytes to bring the device into RDP level 1. The problem however is that there are many unknowns. For example we do not know the right position for the MFI coil and other glitch parameters. Also and most important we do not know the point in time at which we need to inject the glitch. The precise timing is of utmost importance because otherwise it is almost infeasible to find out the other unknown parameters. To determine the exact point in time for a successful glitch we analyze the electromagnetic emission of the microcontroller's boot phase. This figure shows the electromagnetic emission of a small part of the boot phase of the microcontroller. To identify the point in time of the memory transfer that contains the RDP level we use a correlation based leakage test. With help of this leakage test we successfully determine the exact timing. By injecting a fault into the peak highlighted in red we are able to bring the device back into RDP level 1. Now we are able to connect us via the debug interface to the microcontroller and read out the root key directly from the internal SRAM. For the detailed steps, set up parameters and the result of the leakage test I would like to refer you to our paper. The impact of this attack is the same as for the side channel attack but with the advantage that we can also extract the root service key. A clone token containing this key can be used to authenticate against all currently used services and most important against all services that will be used in the future. With a properly built and configured setup we only need a few minutes of physical access to the token to carry out this attack. The root cause of the vulnerability is the read out protection of the tokens microcontroller. Instead of using the most secure RDP level in case of a faulty memory transfer the RDP fallback value enables access to the internal SRAM. Fortunately there are different software based countermeasures that can be implemented. One countermeasure that we proposed and that is already implemented enforces the RDP level during the startup process of the firmware. This basically puts the token always into RDP level 2 and thereby counteracts our downgrade attack. In this presentation I showed you different attacks to raise awareness for evil maid and supply chain attacks on hardware security tokens. My take home message for you is that evil maid and supply chain attacks are realistic threats for hardware security tokens that should be considered more in future products. We showed that token manipulation and even cloning is possible with a few minutes of physical access. This undermines the trustworthness of these products even though the firmware is open source. The open source nature of these products enables independent security audits and thereby increase their trust and security. Instead of wasting valuable time for reverse engineering open source allows us directly to analyze the important parts of the design. Where we encountered closed source components such as the microcontrollers we had to spend some time for reverse engineering but achieved our goal anyway. Unfortunately at the moment you have to choose between security and trust. On the one side you have certified high security smart cards which require NDAs and prevent open source firmware for various reasons. On the other side you have general purpose microcontrollers with closed source hardware but they allow you at least to open source the entire firmware and therefore are trustworthy. The hardware is in fact the only remaining black box in the last missing piece towards a fully open and trustworthy security token. So what we need is not certification of closed source microcontrollers but open source microcontrollers with suitable protection against physical attacks. Unfortunately there will be soon open source microcontrollers like the open titan that consider hardware security and physical attacks right from the design phase. Until that time comes you should continue to use hardware security tokens despite our research findings. They still can protect you against a bunch of password related issues and remote attacks. Also our proposed countermeasures mitigate all of our identified vulnerabilities. If in doubt compile and deploy your firmware on-premise that's one major advantage of open source security tokens. If you have any further questions please do not hesitate to contact us. Thank you for listening.