GD32F103

[tomli at tomli.me]

> At FOSDEM, from a friend, I learned this chip: GD32F103
> It looks interesting.

Thanks for the information. Since I'm working on my FST-01-compatible 
prototype, and just wondering whether there's an "improved" version of this chip
available for experiments.

This is exactly what I need. I never realized the existence of this chip!

> Well, it can run faster (up to 108MHz) and power consumption is lower.
> These benefits themselves are worth to try.  And it's good if we have an
> alternative

Even better, the price of the chip is also lower than its STM32F103
counterpart. In addition, GD32F103 has better ESD-ratings: 4 kV (HBM),
while STM32F103 can only withstand 2 kV, it can increase the chance of
survival of our Gnuk in case of an accident (I've accidentally destroyed
two official FST-01s while trying to reprogram it, ESD is the only possible
explanation came to my mind, so I learned how to properly ground myself
and my workbench as a result, not too bad...)

> It is composed by two dies; A die of serial Flash ROM, and a die of MCU
> core.  Apparently, the flash ROM content is encrypted, but the method is
> unknown (for me).

GigaDevice is knownly for its flash chips so they also incorporated their
flash chips inside the MCU, unsurprisingly. Here are photographs of the	chip's
die: https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices

> The ad says it uses "patented" technology for the encryption, so, some information
> might be available, possibly in Chinese. I wonder if it is more difficult than
> STM32F103 against opening-the-chip attack.

I searched in Chinese, and found the information is limited. If my understanding
is correct, in addition to the standard readout protection, GD32F103 implemented
an algorithm to distribute and map the data on continuous logical addresses to
discontinuous physical address on the flash hardware. Physical attackers need to
rearrange the data to correct orders, so yes, it can probably increase costs of
attacks.

> At least, the encryption can not be controlled by a programmer who writes
> the firmware.

Just like the readout protection, these security features are transparent to
developers, it's good to have them, but we as developers should implement proper
encryption inside the firmware (like the AES encryption in Gnuk) instead not
relying on these hardware features. We'll be okay.

I wonder if we can use a security coprocessor to make an attack more difficult,
without really relying on the security coprocessor.

For example, if we add a SHA coprocessor, we can ask the coprocessor to do an extra
1000-round SHA-HMAC iteration from the key derived by Gnuk with a random salt. In this
way, even if the coprocessor is backdoored and doesn't do anything, Gnuk is still the
bottom line of our security. Users' computing freedom and hackability are also unaffected,
since they are the ultimate controller of the security coprocessor.

It's difficult to find a "secure" MCU without NDA, but it looks like they are lots of
simple TPMs avaliable for the mass market. What is your opinion?

> I would try this chip, if I will have an opportunity.  It seems that
> 36-pin QFN version is not yet available at aliexpress.

I just placed an order for this chip, and I'm going to try the chip as soon as I receive
them. Perhaps I can send a few pieces to Japan via FedEx? I also found some Chinese application
notes for porting the program, and some posts on the Internet that document some traps of
the chip, I'd like to translate them to English if it is useful for Gnuk development.

Finally, I remembered seeing a post about a possible future design of the FST-01 board,
including drawing the USB traces on the PCB instead of using a external connector, and
the possible shift to newer chips, but I cannot find the mail anymore. Can you send me
a link?

Happy Hacking,
Tom Li
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 851 bytes
Desc: Digital signature
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20180207/d7f25e3f/attachment.sig>