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: STM32F103 flash ROM read-out service
On 06/06/2018 08:50 PM, Philipp Klaus Krause wrote: > See https://www.aisec.fraunhofer.de/en/FirmwareProtection.html for > some research on breaking STM32 readout protection published in > January. For what it's worth, STMicroelectronics claims that the attack described in this paper "affects only the STM32F0 and is not successful in all other series" [1]. Whether you believe them or not is up to you. Of note, the authors of that paper themselves do not claim the attack works on anything else than the STM32F0. (But of course, just because *this* attack (presumably) does not work on the STM32F103, it does not mean that nobody can ever come up with a successful attack on that chip...) Damien [1] https://community.st.com/thread/46432-hacking-readout-protection-on-stm32#comment-181542 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STM32F103 flash ROM read-out service
Am 05.06.2018 um 02:37 schrieb NIIBE Yutaka: > Hello, > > 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). > > Well, I encourage Gnuk users to new use KDF-DO feature with newer GnuPG. > See https://www.aisec.fraunhofer.de/en/FirmwareProtection.html for some research on breaking STM32 readout protection published in January. Philipp signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: efail is imho only a html rendering bug
Hi! Thanks for responding. However, my question was related to the claims in the paper about using CRL and OCSP as back channels. This created the impression that, for example, the certificates included in an encrypted CMS object could be modified in a way that, say, the DP could be change in the same was a a HTML img tag or to confuse the MIME parser. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp5uoT9g_wwT.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STM32F103 flash ROM read-out service
Relevant discussion is moved to [gnuk-users], but in case someone has seen the first mail in [gnupg-users] but missed other mails, I've reposted the mail, sorry for the double post. Follow-up discussion should be sent to [gnuk-users]. - > 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) Se
Re: efail is imho only a html rendering bug
Am 06.06.2018 um 10:04 schrieb Werner Koch: > On Mon, 21 May 2018 19:11, r...@sixdemonbag.org said: > >> Efail is not just an HTML rendering bug. It includes very real >> attacks against S/MIME as it's used by thousands of corporations. > > I have not yet seen any hints on how a back-channel within the S/MIME > protocol can work. There are claims that this can be done with CRLs and > OCSP but that all requires substantial implementaion bugs in the S/MIME > engines. The paper presents only vague ideas. Did I miss something? A backchannel in a technology is not a vulnerability per se. At its core, the Efail CBC/CFB gadget attack modifies a ciphertext in a way that it *exfiltrates its own plaintext* when opened. The paper shows that this is practical for HTML email clients. The generic concept of the CBC/CFB gadget attack, however, is neither limited to HTML, nor to emails. It is plausible to transform the attack to other data formats supporting backchannels. It's up to the creativity of the attacker to come up with other scenarios. Adam Langley touched another scenario already in 2014: https://www.imperialviolet.org/2014/06/27/streamingencryption.html The central flaws for CBC/CFB gadgets to work are (a) missing authenticated encryption in S/MIME and (b) not properly enforced integrity protection in OpenPGP. We won't fix malleable encryption by tinkering with HTML, x509 and MIME parsers. Best, Sebastian ___ 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
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 ___ 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
Re: doc patches: spelling errors
Hi! Thanks for the fixes. I applied them to master and 2.2 > +++ gnupg.info-1 Sat May 19 19:02:04 2018 Noet that this is a generated file. The source is one of the *texi files. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp0ifXZ3aIp8.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: efail is imho only a html rendering bug
On Mon, 21 May 2018 19:11, r...@sixdemonbag.org said: > Efail is not just an HTML rendering bug. It includes very real > attacks against S/MIME as it's used by thousands of corporations. I have not yet seen any hints on how a back-channel within the S/MIME protocol can work. There are claims that this can be done with CRLs and OCSP but that all requires substantial implementaion bugs in the S/MIME engines. The paper presents only vague ideas. Did I miss something? Note that when talking about S/MIME I actually mean the CMS/X.509 part and not the MIME part of it. For sure the same MIME parser bugs a few OpenPGP MUAs showed will also work with S/MIME - and even easier due to the missing intgerity protection at the crypto level. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp_BaEbVgW02.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking changes
On Wed, 23 May 2018 15:45, m16+gn...@monksofcool.net said: > 1. GPG is maintained by volunteers. If you have any complaint about how > this maintenance is progressing, get off your behind and be a volunteer That is fortunately not true. I work full time on GnuPG and related software, Gniibe is working at least half-time on it, Ben started to work half-time and Andre spends most of his paid time on Gpg4win and also GnuPG. This is possible due to our generous donors as well as from a few successful projects we did in the last 3 years. > 2. GPG 1.4 will not suddenly vanish if it is no longer maintained. > People can still use it like before. Maybe they shouldn't, but they can. Right; we keep it - it is important to have a way to decrypt old data. Some minor changes will be done over time but for example, mitigation's against side-channel attacks and such won't happen. It does not require a lot of resources. > What I percieve a lot in this thread are variations of "I wanna stay in > bed for five more minutes mommy". I wonder if Werner and Robert should :-) Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp_g3ouGxfYj.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
end-of-life announcements (was: Breaking changes)
On Wed, 23 May 2018 13:56, d...@kegel.com said: >> So when talking about EOL, gpg community should consider writing down a >> consistent EOL strategy, similar to those of Ubuntu, Linux kernel or others >> or something like I tried to argue for in the middle of >> https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060539.html > > Yes, exactly! We announce EOL early. Check the AUTHOR file of each package. For example Libgcrypt 1.7: Library: Libgcrypt [...] End-of-life: 2019-06-30 That was set with the last release (1.7.9) on 2017-08-27. Two years are pretty long given that even the new branches are ABI and API compatible. For GnuPG 2.2 the things are not that easy. We knew that we would need a longer transition period, thus despite that 2.1.0 would have been a development version, we urged people to start using 2.1 asap. This was due to the fact that many distributions still used the legacy 1.4 and not the stable 2.0. > To be kind to enterprise customers, GnuPG could pick one of > those two dates as the EOL for 1.4. Matching 16.04's EOL There is no EOL planned for 1.4 but 1.4 shall not be used except when you need compatiblity for the broken PGP 2 or you have a very exotic and ancient platform. But in the latter case you have all kind of other problems than to care about gpg versions. > Also, gnupg.org should add a web page like > https://www.gnupg.org/release-end-of-life Good idea. However, I think it is better to add it to the download page. Which I just did: PackageBranch Birth End-of-life EOL - GnuPG 1.0 1999-09-07 2002-09-07 yes 1.2 2002-09-21 2005-01-01 yes 1.4 2004-12-16 (1) 2.0 2006-11-11 2017-12-31 yes 2.2 2014-11-06 tba Libgcrypt 1.5 2011-06-29 2016-12-31 yes 1.6 2013-12-16 2017-06-30 yes 1.7 2016-04-15 2019-06-30 1.8 2017-07-18 tba tba: To be announced. (1): Legacy version; see remarks above. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp2WAdp2UY1a.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Invitation to the 4th OpenPGP Email Summit
I'm happy to announce the 4th OpenPGP Email Summit which will take place Saturday, October 20 until Sunday, October 21, 2018 in Brussles (Belgium). This is an event open for anybody involved in the development of email clients using OpenPGP for encryption, and related software. In 2015 and 2016 we already had tree OpenPGP Email Summits. These are meetings by technical experts of projects and tools dealing with OpenPGP with a focus on email encryption. The goals are to better get to know each other, and to discuss and work on several technical issues that hopefully improve certain aspects of OpenPGP-based email encryption. For details, see https://wiki.gnupg.org/OpenPGPEmailSummits REGISTRATION If you want to attend, please *send an informal email* to: patr...@enigmail.net I will then let you know more details about the location, hotel, etc. If you need funding for your travel/hotel expenses, then please also get in contact with me. NOTES = This is a meeting of those who develop software. Thus, we will have a lot of tech talk about key servers, key exchange, subject encryption, password recovery, etc. If you just are interested in these topics as a user, you probably will be bored to death ;-). Thus, feel free to join us if you are working in the area of - TECHNICAL DETAILS - for SENDING or PROCESSING ENCRYPTED EMAILS - with OpenPGP - in a project or product. Note however, that due to capacity reasons we cannot have more than 1-2 people from each project. We can host about 30 attendees. Note that this is still neither a well-organized conference nor a commercial meeting. The agenda will be driven by the attendees. Anyone may propose any topic for discussion, as long as he/she is ready to lead the discussion. More details are/will be available on the web site: https://wiki.gnupg.org/OpenPGPEmailSummit201810 Looking forward to meet you in Brussels -Patrick -- Patrick Brunschwig mailto:patr...@enigmail.net PGP fingerprint: 4F9F 89F5 505A C1D1 A260 631C DB11 87B9 DD5F 693B signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
