GD32F103

[tomli at tomli.me]

> > I wonder if we can use a security coprocessor to make an attack more
> > difficult, without really relying on the security coprocessor.
>
> In general, I don't want such a feature in device side.  It could be a
> honey-pot.  Or, it tends to be immature like ROCA problem.

Yes, this problem is a serious concern. 

The idea is to make it fail-safe, in other words, use the security coprocessor
without trusting it, double-encrypting the already-encrypted data. If the security
coprocessor is a honeypot, the worst-case scenario is merely a denial-of-service
attack.

Unless the coprocessor is customized to launch a hardware-level exploit to the
main processor, e.g. doing a power-analysis in real time when the main chip is
being used, and saving the results inside the chip for attacks to gain physical
access later.

These security coprocessors are mainly design to prevent low-cost opening-the-chip
attacks by the competitors to copy their programs on mass-market products, rather
than cryptography applications. It looks like there are some, don't even require
an NSA^H^H^H NDA. These coprocessors may be ineffective, but I don't think they are
capable to do these types of malicious attacks.

So I don't think there is a problem on security, but in my opinion, the bigger problem
is the lack of free software toolchains (no idea about their toolchains) for these
coprocessors, but it seems easy to port existing tools since they are using the same
common commodity "IP" cores like 8051. Debugging might be another problem.

You may not prefer these popentially-questionable chips, but for me I think it's worth to
investigate the good, the bad, and the ugly about them. I have a few candidates and I'm
going to report everything I have discovered.

> To achieve same, it's far better done in host side.  In OpenPGP card V3
> specification, I proposed KDF Data Object, so that host side can do more
> iteration:
> 
>     https://dev.gnupg.org/T3152
> 
> In recent Gnuk, it is already implemented.  Host side implementation is
> ready in GnuPG, just waiting next release.  https://dev.gnupg.org/T3201

Well done, this is exactly what we need. It's going to dramatically increase
our last-line resistance of brute-force attacks after the chip is opened.

> Do you mean this?
> 
>     https://www.gniibe.org/memo/development/fs-bb48/fs-bb48-idea.html
> 
> I made prototype.  It found that the multiplier is too slow in
> Cortex-M0+.  It would be OK for ECC though.
> 
> For FS-BB48, I designed 3D part:
> 
>     https://git.gniibe.org/gitweb/?p=gnuk/fs-geta083.git
> 
> In 2016, I was unable to find better way to manufacture something like
> FS-GETA083.  At that time, using standard USB-A plug is more cheaper and
> easier.
> 
> Thus, in 2016, my conclusion was update to FST-01G.
> 
>     https://www.gniibe.org/memo/development/fst-01/fst-01-revision-g.html

Bookmarked.

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/8d33b458/attachment.sig>