From gniibe at fsij.org Wed Jun 6 04:22:59 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 06 Jun 2018 11:22:59 +0900 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service Message-ID: <87vaawslfg.fsf@iwagami.gniibe.org> Hello, I should have write to gnuk-users, at first. -------------- next part -------------- An embedded message was scrubbed... From: NIIBE Yutaka Subject: STM32F103 flash ROM read-out service Date: Tue, 05 Jun 2018 09:37:19 +0900 Size: 2864 URL: -------------- next part -------------- If anyone has information in detail, please let us know. -- From tomli at tomli.me Wed Jun 6 17:49:07 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Wed, 6 Jun 2018 23:49:07 +0800 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: <87vaawslfg.fsf@iwagami.gniibe.org> References: <87vaawslfg.fsf@iwagami.gniibe.org> Message-ID: <20180606154907.GA73725@x220> > 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_36568888/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 STM32 ROM. Reverse this process for decryption. Essentially, we encrypt our data twice, first by ourselves on STM32, then by the chip with its internal key. The two keys are both derived from the User PIN on-the-fly during runtime, cryptographically independent of each other. As soon as power is removed, the attacker is forced to break the security chip, the STM32 chip, and our original encryption, three times in a row. ----- > Well, I encourage Gnuk users to new use KDF-DO feature with newer GnuPG. Yes, KDF-DO should be an essential protection. A six-word diceware passphrase is also recommended. All to be said, we don't really know if the "STM32 Cracking" service really works. Perhaps we can launch a funding campaign to accept donations, and find one company to actually pay them to attack our existing Gnuk systems, and see if they can recover the encrypted data from ROM. Happy Hacking, Tom Li Beijing GNU/Linux User Group. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: From ndk.clanbo at gmail.com Wed Jun 6 18:56:29 2018 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 6 Jun 2018 18:56:29 +0200 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: <20180606154907.GA73725@x220> References: <87vaawslfg.fsf@iwagami.gniibe.org> <20180606154907.GA73725@x220> Message-ID: <3f347da5-13c6-da21-0b44-3c2801fde5cd@gmail.com> 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. IIRC some recent chips reused (partially) that idea, rebranded under "Physically Unclonable" something. Yep... Found: https://community.cadence.com/cadence_blogs_8/b/breakfast-bytes/posts/secret-key-generation-with-physically-unclonable-functions (but looking for "physically unclonable chip" returns lots of results). Those chips work on the same principle: decapping alters the silicon layers and the 'random id' changes before the attacker have a chance to read it. > 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. Then we should all use RISC-V chips :) > 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 Too bad neither ETECC508A nor ATECC608A support curve25519 :( Only some NIST ones. > 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. Well, at least some TPM 1.2 chips have already been cracked. > 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. Yes, but you risk having very long delays, that could even be unacceptable. Unless there's a way to parallelize the operations (say 'do more KDF iterations while the chip is decoding'). > All to be said, we don't really know if the "STM32 Cracking" service really > works. Perhaps we can launch a funding campaign to accept donations, and > find one company to actually pay them to attack our existing Gnuk systems, > and see if they can recover the encrypted data from ROM. I'd bet it works as described in the offers. BYtE, Diego From gniibe at fsij.org Thu Jun 7 02:26:53 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 07 Jun 2018 09:26:53 +0900 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: <20180606154907.GA73725@x220> References: <87vaawslfg.fsf@iwagami.gniibe.org> <20180606154907.GA73725@x220> Message-ID: <87lgbrbfw2.fsf@iwagami.gniibe.org> Hello, Continues at gnuk-users... tomli at tomli.me wrote: > 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... Generally speaking (not specific to this chip and this context), I think that disassembly of IC cap is not that hard. And once the chip is analyzed to locate its flash ROM part, the flash ROM content may be accessible by data+address lines directly. In this context, GD32F103 is considered easier to break (after disassembly of IC), because of its composition of MCU part and flash part. So, for me, it's no wonder they need to claim they have countermeasure(s). > 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. Thanks for your references. I think that market size matters. For reading out proprietary program (for copying product), there would be more demand. For reading out private material, it would violate laws in many countries. So, even if it's possible technically, it would not be advertised like pcbcopy.com does so for STM32F103. That's my consideration. I am not sure if the service itself can be profitable. But, claiming they can do that, it sounds like they have enough technology. And it is true that it is an important part of copying a product and its PCB. > 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. ... provided it can be manufactured independently with reproducibility (as NdK points out in another expression). I think that dependency to specific company matters. And... when you use a "secure" chip, how can you measure their claim to be "secure"? In my opinion, it should be possible to be evaluated by independent party. Furthermore, if some technology is available for a chip to be "secure", it is good for users of semiconductor to ask applying the technology to improve some other chips. My point is that it's not only obscurity, but it's too far to be scientific. I wonder the reason why people can rely on that, seriously. > Now I have plans to experiment with the ATECC508A chip by Atmel Good. If it's going well (or not), I would recommend to make a chip with similar functionality or more (as NdK suggested another curve). > 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. It is true some specification is available to produce hardware (a board of PC with the chip), but... I have a TPM chip from Infineon, but the spec how to use it (independently, out of scope of TCG) is not available to public, as far as I know. In some cases, for my experience, it requires NDA documents, non-free tools and drivers/libraries. At leaset, Infineon suggested so. But I'm an old engineer, the situation may be changed now. Could you please let me know if any specification is available? Then, making something like Yubikey or Nitrokey Pro, using a TPM chip will be possible. > All to be said, we don't really know if the "STM32 Cracking" service really > works. Perhaps we can launch a funding campaign to accept donations, and > find one company to actually pay them to attack our existing Gnuk systems, > and see if they can recover the encrypted data from ROM. Please make sure it doesn't violate any laws and regulations, if someone is going ahead. In my opinion, these things (evaluation how secure a chip is) should be possible, in some scientific ways, not only for Gnuk (or for STM32F103), but for general cases. -- From ndk.clanbo at gmail.com Thu Jun 7 13:01:55 2018 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 7 Jun 2018 13:01:55 +0200 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: <87lgbrbfw2.fsf@iwagami.gniibe.org> References: <87vaawslfg.fsf@iwagami.gniibe.org> <20180606154907.GA73725@x220> <87lgbrbfw2.fsf@iwagami.gniibe.org> Message-ID: Il 07/06/2018 02:26, NIIBE Yutaka ha scritto: > ... provided it can be manufactured independently with reproducibility > (as NdK points out in another expression). I think that dependency to > specific company matters. Expecially because you have no control over the finished product: if they decide to add a backdoor after you vetted the chip, you can't know. Unless there's a continuous vetting process (over any batch, decap X% chips to check). > And... when you use a "secure" chip, how can you measure their claim to > be "secure"? In my opinion, it should be possible to be evaluated by > independent party. That's usually the "certified" part. Too bad too often they tell a device is certified against a norm, but they don't tell exactly what got certified (unless it's mandated by the norm, but that's quite rare). Was it just hardness against flash reading? What about invasive attacks? And side-channel ones? Too often (controllers from Microchip, just to say one) there's note that the protection only works if the device is used as specified: ROFLASTC! An attacker will do anything... running it out of spec is the most basic attack, usually way easier than decapping. > Furthermore, if some technology is available for a chip to be "secure", > it is good for users of semiconductor to ask applying the technology to > improve some other chips. It's just a matter of costs. If it adds a fraction of a cent to the cost, it's not suitable for the cheap chips. Probably the countermeasures needed for "military grade" smartcards add 2-3 cents to the chip cost (probably less). > Please make sure it doesn't violate any laws and regulations, if someone > is going ahead. Worth verifying, but having *my* secrets extracted from *my* device should not violate laws. But after that is the extracted data still a secret at all? > In my opinion, these things (evaluation how secure a chip is) should be > possible, in some scientific ways, not only for Gnuk (or for STM32F103), > but for general cases. You can choose the standard for having the device certified. And define the exact attack scenario. Then pay. A lot, usually. :( BYtE, Diego From gniibe at fsij.org Thu Jun 7 14:35:41 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 07 Jun 2018 21:35:41 +0900 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: References: <87vaawslfg.fsf@iwagami.gniibe.org> <20180606154907.GA73725@x220> <87lgbrbfw2.fsf@iwagami.gniibe.org> Message-ID: <87h8melqoy.fsf@fsij.org> I wrote: > And... when you use a "secure" chip, how can you measure their claim to > be "secure"? In my opinion, it should be possible to be evaluated by > independent party. NdK wrote: > You can choose the standard for having the device certified. And define > the exact attack scenario. Then pay. A lot, usually. :( I know something called "Protection Profile" or certification which is required to offer devices to government. Protection Profile: Eurosmart PP/9806, SSVG-PP of BSI, or JICSAP PP/0301. Or, FIPS140-2 and FIPS140-2 DTR would be interesting document. Or, we have Common Criteria for Information Technology Security Evaluation. IMNSHO, those certification assume (and allow) proprietary technology. And evaluation for certification is too rough (for me). For example, many side channel attacks have been invented. BTW, I know a company in Japan which offers a service to decap a IC chip and to repair somthing by FIB in two days. I don't know how much does it cost. If the read-out from flash method to STM32F103 is modifying protection bit and simply use JTAG/SWD debugger, it takes two days + some. -- From ndk.clanbo at gmail.com Thu Jun 7 14:54:54 2018 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 7 Jun 2018 14:54:54 +0200 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: <87h8melqoy.fsf@fsij.org> References: <87vaawslfg.fsf@iwagami.gniibe.org> <20180606154907.GA73725@x220> <87lgbrbfw2.fsf@iwagami.gniibe.org> <87h8melqoy.fsf@fsij.org> Message-ID: <94edba30-0867-bfcb-0e2a-f0a074a3b0db@gmail.com> Il 07/06/2018 14:35, NIIBE Yutaka ha scritto: > IMNSHO, those certification assume (and allow) proprietary technology. > And evaluation for certification is too rough (for me). > For example, many side channel attacks have been invented. Yes, certifications can only state that the known attacks won't work. They can't say anything about new ones. Can't be different. When you buy a strong door, they can certify that the lock can't be forced with known methods. But usually don't say anything about the window left open :) > BTW, I know a company in Japan which offers a service to decap a IC chip > and to repair somthing by FIB in two days. I don't know how much does > it cost. If the read-out from flash method to STM32F103 is modifying > protection bit and simply use JTAG/SWD debugger, it takes two days + > some. The best we can do is keep that as a baseline. It requires 2 days? OK. If my GnuK token disappears for more than 24h I know I have to revoke my keys before they can crack KDF. That's a big plus against keys stored on disk because I can see that the token is actually missing (say because I have to use it every day): they physically need it to carry out the attack. That's more or less the same thing I'm studying for my domotic system: if a node goes offline for more than 'x' minutes, it's considered captured and kicked out. I think there's no other way (in my case, with ESP8266, it's even worse: it can be read in a couple of minutes). BYtE, Diego From tomli at tomli.me Fri Jun 8 05:35:32 2018 From: tomli at tomli.me (tomli at tomli.me) Date: Fri, 8 Jun 2018 11:35:32 +0800 Subject: [NIIBE Yutaka] STM32F103 flash ROM read-out service In-Reply-To: <87lgbrbfw2.fsf@iwagami.gniibe.org> References: <87vaawslfg.fsf@iwagami.gniibe.org> <20180606154907.GA73725@x220> <87lgbrbfw2.fsf@iwagami.gniibe.org> Message-ID: <20180608033532.GA13329@x220> > My point is that it's not only obscurity, but it's too far to be > scientific. I wonder the reason why people can rely on that, seriously. The reason is simple, there is no other options. To an extent, the internal details of all hardware is inaccessible. You may program a RISC-V CPU on a FPGA, but the operation of the FPGA is ultimately inaccessible. But RMS believed this is the result of the nature of hardware - software is more like a set of abstract instructions, or ideas, but hardware, as it is today, mere physical objects. While it is a good thing to apply the princple of free software to hardware design, just like you did in FST-01, for chips and many types of other hardware, most of the time it's not possible, and sometimes not even needed to. Perhaps in the future the chips can be made just like how small prototypes is made by 3D printer. "In the meantime, there is no need to reject hardware with nonfree designs on principle." Therefore, many problems of crypto chips also exist on nearly all types of chips. On the one hand, you have standard embedded controllers with inaccessible internal details, on the other hand, you have specialized crypto chips with inaccessible internal details. Provided tools and documentations for development is freely available, of course, you can assume the crypto chips, actually, may not be more secure than the standard embedded controllers as advertised. In the same time, it is also unreasonable to think a standard embedded controller is superior to the crypto chip. Probabilistic speaking, the crypto chip should have included more counter- measures, and it should be at least a little more expensive to crack. Think about it, if nothing made a crypto chip inherently more "sinnful" than any other chips, why are we keep questioning it? Just like what we are doing now? I think the reason is that the crypto chips are "advertised" and "guaranteed" to be secure, and that where all the troubles begin. If these chips are never claimed to be secure, I guess we won't have problem with them. Bascially, I don't think the crypto chips are evil by themselves, I completely agree independent verification of its security claim is an issue. Meanwhile, the best thing we can do is avoid chips with private specs and tools, and stick to common commodity chips as much as possible. Thanks to IoT, we now have chips like ATECC508A that are expected be to use as a common component in IoT device, just like a MCU, and I expect more and more similar products enter the market. Then at least we'll get some standard crypto chips of choices that are made by lots of manufacturers. We should also expore the option that doesn't require us to trust the crypto chip completely. These, at least, can make us feel a little more confident... > > Now I have plans to experiment with the ATECC508A chip by Atmel > Good. If it's going well (or not), I would recommend to make a chip > with similar functionality or more (as NdK suggested another curve). The algorithms or curves the chip uses doesn't even matter in this case I believe, all it is needed to do is sealing a secret key inside, no matter it's an AES key, a NIST P-curve private key, or even a 3DES key, since the chip is only used for the outer-layer of encryption of key storage. But as pointed out beforehand, the latency of this scheme may be unacceptable, and one may have to offload the crypto computation to the chip, and this is unacceptable to me. I'll find out whether it is the case or not soon. > I have a TPM chip from Infineon, but the spec how to use it > (independently, out of scope of TCG) is not available to public, as far > as I know. In some cases, for my experience, it requires NDA documents, > non-free tools and drivers/libraries. At leaset, Infineon suggested so. > > But I'm an old engineer, the situation may be changed now. > > Could you please let me know if any specification is available? Then, > making something like Yubikey or Nitrokey Pro, using a TPM chip will be > possible. I made a mistake. Apparently TCG was all it's needed to use the chip, but it is not? Can't one just use a subset of the crypto in TCG spec to implement a "secret-sealing" scheme? Or the TCG spec is just for the TPM module on PCs, the chip itself is still locked behind proprietary specs? Happy Hacking, Tom Li Beijing GNU/Linux User Group -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: Digital signature URL: