Re: [NIIBE Yutaka] STM32F103 flash ROM read-out service
Il 07/06/2018 02:01, Leo Gaspard via Gnupg-users ha scritto: >> The only secure (even against decapping attacks) device I know of is a >> very old parallel-port "key" a friend described me ~25y ago. >> It was made of 3 silicon layers: the outer ones only contained interface >> circuits and 'randomness' while the keys and the logic were in the >> central layer. Trying to remove the outer layers destroyed the random >> patterns that were used as 'internal master key', rendering the rest >> completely useless. > Some people do reverse-engineering based on photons emitted by > transistors switching. These would get through this shielding. > Unfortunately, I can't find again the link to the conference talk where > I heard people explaining they did that… sorry. I think I've seen it. But IIRC it does not work with such a big slice (whole depth of the silicon slice, ~200micron IIRC). But now that you made me think about it, I remember I've seen another article where the attack was carried out from "behind" the chip. > Another kind of attack would be EM pulses / lasers for error-ing a > crypto computation, that would get through this shielding too. Fault-injection. But for cheap chips it's probably way easier to "just" use FIB (or a laser) to change the state of the protection fluses (usually just normal flash cells) then read the whole contents. > There are defenses against these attacks (well, for the > transistors-emitting-photons attack I'm not really sure), that are > deployed in secure elements. Attacks like this are tested by CC/EAL > evaluation laboratories. Hope so :) But I stay cautious when trusting certification. See the ROCA vulnerability in Infineon "secure" (smartcard) chips. > All that to say: hardware security, to me, is a way to increase the cost > of the attacker to perform an attack. All devices are eventually > vulnerable, given the right price, the point is to make attack more > costly than the benefit from breaking the card and/or than finding a way > around the card. (I'm not going to extend this point to software > security, but I'd think it most likely holds there too) Then, instead of "this chip is secure" they should just say "this chip can be cracked spending X in equipement (una tantum) and Y for every chip"... Marketing would never allow that :) > Oh, and also to say: choosing between a non-secure-element open-source > token and a secure-element NDA-ed-and-thus-non-open-source token is not > an obvious choice. As always it depends on the attack scenario. GnuK IIUC targets all those users who think a targeted attack is quite improbable or that rubber-hose cryptanalysis is end of game. If I know that extracting my key from the token costs $500, then I can choose what to do. But with a non-secure and open chip it's easier to estimate that cost (being easier and cheaper, it's more probable it gets used in universities by security students for their first attacks, usually the most fantasious ones). Quite surely it will be lower than the cost of attacking a secure chip, but probably by not that much. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [NIIBE Yutaka] STM32F103 flash ROM read-out service
On 06/06/2018 06:56 PM, NdK wrote: > Il 06/06/2018 17:49, Tom Li via Gnuk-users ha scritto: > >> BTW, BasicCard and JavaCard seemed even more obscure and I cannot find >> any public service of cracking. > Because those are (at least should be) based on secure chips. > >> But it does not solve any real problem in the perspective of cryptography. >> They are all "security through obscurity" at best, just driving out script >> kiddies (or equipment kiddies?) at worst. > The only secure (even against decapping attacks) device I know of is a > very old parallel-port "key" a friend described me ~25y ago. > It was made of 3 silicon layers: the outer ones only contained interface > circuits and 'randomness' while the keys and the logic were in the > central layer. Trying to remove the outer layers destroyed the random > patterns that were used as 'internal master key', rendering the rest > completely useless. Some people do reverse-engineering based on photons emitted by transistors switching. These would get through this shielding. Unfortunately, I can't find again the link to the conference talk where I heard people explaining they did that… sorry. Another kind of attack would be EM pulses / lasers for error-ing a crypto computation, that would get through this shielding too. There are defenses against these attacks (well, for the transistors-emitting-photons attack I'm not really sure), that are deployed in secure elements. Attacks like this are tested by CC/EAL evaluation laboratories. All that to say: hardware security, to me, is a way to increase the cost of the attacker to perform an attack. All devices are eventually vulnerable, given the right price, the point is to make attack more costly than the benefit from breaking the card and/or than finding a way around the card. (I'm not going to extend this point to software security, but I'd think it most likely holds there too) Oh, and also to say: choosing between a non-secure-element open-source token and a secure-element NDA-ed-and-thus-non-open-source token is not an obvious choice. HTH, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [NIIBE Yutaka] STM32F103 flash ROM read-out service
> While learning Chinese language, I found this service (in Chinese): > > http://www.pcbcopy.com/2016/ic_1128/1928.html > > IIUC, It's a company in ShenZhen, which offers a service reading out > from protected STM32F103, even if it uses anti-tamper feature with a > battery. > > I was aware of similar services for PIC18 or ATmega (in different > country). This is new for me, specifically for STM32F103. > > I don't know the detail of this service, but it seems that it's not that > expensive (from not-confirmed information by my friend). - These services have came into existence as early as 2012. It is a main way used to create cheap clones by rogue competitors of products on the existing market. It's commonly believed STM32F1 is easy to crack, both through physical IC decapping, or by mounting a fault injection attack to disable the flash readout protection, or exploting the bootloader, who knows... You can search the keywords "STM32F1 破解" (STM32F1 Crack) in Chinese and you'll find many advertisements and victims of copycat complaining in EE forums. While GD32 seems to include more countermeasures in the chip, relatively obscure and have a higher cost of attack, I can only find one company or two cracking GD32, compared to lots of companies for STM32. BTW, BasicCard and JavaCard seemed even more obscure and I cannot find any public service of cracking. See: [1] http://blog.sina.com.cn/s/blog_770bd2000100zssn.html [2] http://www.stmcu.org/module/forum/thread-608097-1-6.html [3] http://www.pcbhf.com/xinpianjiemi/icxinghaopanding/320.html [4] https://blog.csdn.net/sinat_3656/article/details/52984056 - Common countermeasures in the industry vaires, including... 1. Use high voltage to destroy most I/O pins to render most inputs useless, creating a smaller attack surface. 2. Hardcode chip UUID, using "security through obscurity" to refuse program execution if a unknown ID has been detected. 3. Use proprietary secure chips that come with NDAs. But it does not solve any real problem in the perspective of cryptography. They are all "security through obscurity" at best, just driving out script kiddies (or equipment kiddies?) at worst. As I have said in the gnuk-users list, the only way to solve this problem is using something like a secure chip, a TPM, or a cryptography coprocessor. It is very important, but the free software community never trusted these devices, because they can be used to carry out "trusted computing" vendor lock-in, implement DRM, implant backdoors, etc. My point is, if these hardware is instructed exclusively by Free Software, the ultimate master of these devices are their users, and none of these will be a problem. So, we need to find a security chip that comes with OPEN, PUBLIC specs, so we can develop free software for it. - In the beginning of this year, I have done some researches for this project, I've found... Thanks to the emergence of the "Internet-of-Trash", security of embedded devices have became a real demand, so many manufacturers now have simple security chips that do not require any NDA nor subject to any cryptographic regulations, yet, they are basic versions of secure chips that can seal keys. They may not as temper-proof as a proprietary ST31 chip, but is a huge improvement compared to generic microcontrollers. Now I have plans to experiment with the ATECC508A chip by Atmel, if I have time. It looks like a simple security chip with full specs, and suitable to be used with Gnuk. The datasheet is interesting, see [5] http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pdf Also, the TPM chips found on x86 systems are really underestimated by the Free Software community, since it's a mass-produced commodity chip with full spec available. - To prevent the chip becoming a single point of failure, we can implement "split-secret" or "double-encryption" scheme. This allows us to use the security chip in a trustless manner - a offline attacker needs to break both STM32F1 and the security chip, before getting access to the key material. No matter what have happened to the chip, the key is still as secure as the original STM32F1 + KDF-DO. For example, if a security chip allows us to encrypt and decrypt data with its internal key, but only after a correct PIN code is provided, a simple scheme can be: 1. Enter PIN 2. PIN = KDF(PIN) 3. K1 = HMAC-256(PIN, sqrt_2) 4. K2 = KMAC-256(PIN, sqrt_3) So K1 and K2 is now two independent keys. It's just an example for simplicity, a secure system should use standard, proven cryptography, like the "Expand" stage of the "Extract-and-Expand" KDF specified in RFC5869. [6] https://tools.ietf.org/html/rfc5869 5. (chip) Reset chip 6. (chip) Set security chip PIN to K2 7. (chip) Generate a new secret key on chip When storing our secret, 8. Encrypt key material with K1 on STM32, output known as C1 9. Encrypt key material with K2 on chip, output known as C2 10. Save C2 to
