Chopstx 2.4 and Gnuk 2.1

[NIIBE Yutaka]

Hello,

Chopstx 2.5 was released in STABLE-BRANCH-2.

	tag release/2.5
	Tagger: NIIBE Yutaka <gniibe at fsij.org>
	Date:   Tue Sep 5 10:14:51 2023 +0900
	commit d934006a4ac40946fea9ee97fed5f21990ff5228

It includes drivers (USB and ADC) for GD32VF103.  Perhaps, NeuG can run
on GD32VF103.  (I don't think it's good idea to run Gnuk on GD32VF103,
because its flash ROM content can be accessed easily.)

Please note that it now uses picolibc in rules.mk.  If you
want to use newlib, you need to modify the rules.mk.

In this summer, I checked CH32V203 from WCH (RISC-V MCU), which looks
good.

    https://github.com/openwch/ch32v20x/tree/main/Datasheet

I don't evaluate the board with the chip (yet).  I wonder if its ISP
protocol can be secure.  I have a look at:

    https://github.com/ch32-rs/wchisp

But I can't find technical document for the ISP protocol from vendor.
If anyone knows, please let me know.

And then, Gnuk 2.1 was released.

	tag release/2.1
	Tagger: NIIBE Yutaka <gniibe at fsij.org>
	Date:   Tue Sep 5 14:52:54 2023 +0900
	commit c7a98b7d13d770a6850f4306f801e57d8be26481

>From NEWS, here is major changes in Gnuk 2.1

* Ed448 and X448 support.
Ed448 and X448 support are added.  This support is experimental.

* Removal of RSA support.
RSA support has been removed.

* Removal of NIST P-256 support.
NIST P-256 curve support has been removed.

* Removal of debug option at configure (--enable-debug).
Debug option with CDC-ACM has been removed.  Please have a JTAG/SWD
debugger and use GDB.

* Removal of highly experimental pinpad support.
Pinpad support has been removed.

* Removal of old test.
We had old tests under "test/" directory which used python-nose.  We
switched to pytest and it's now under "tests/" directory.

* Replace AES implementation for encrypting secret keys on flash.
Secret keys on flash is encrypted with AES-GCM-SIV.  We now use
AES-256 implementation of our own.

* Change of authentication for firmware upgrade.
In Gnuk 1.2, we registered an RSA public key for firmware upgrade.
The RSA key is used by Gnuk Token to do challenge-response
authentication, so that only the secret key holder of RSA can do the
firmware upgrade.  In Gnuk 2, PIN authentication for Admin is used
for firmware upgrade.

* Upgrade of Chopstx
We use Chopstx 2.5.  It uses picolibc (instead of newlib).


Basically, many removal of old code.  Please note that RSA has gone (as
well as NIST P-256).

Ed448/X448 is introduced.  I thought that AES with 128-bit doesn't match
to encrypt the secret keys for Ed448/X448 (when we consider the weakest
link).  So, I use AES-256 now.  I thought that AEAD scheme should be
used.  My choice here is AES-GCM-SIV.  (In Gnuk 1, the secret key is
encrypted by AES CFB, and it has a checksum.)


I tested Gnuk 2.1 with GNU/Linux emulation, FST-01, and FST-01SZ.
Please use JTAG/SWD debugger to install Gnuk 2.1.  Installing by
upgrade_by_passwd.py is a bit compilicated, because the method is
different between Gnuk 1.2 and Gnuk 2.1.  If your Gnuk Token runs Gnuk
1.2, you need to use the upgrade_by_passwd.py tool of Gnuk 1.2.


			*	*	*


For ECC support, I think that GD32F103 (or STM32F103) is still good.  If
its ISP protocol is good, CH32V203 from WCH would be next candidate.

Then, I'm considering PQC support.  There are two technical issues.

(1) Time (by its hybrid scheme)

PQC will be used together with existing ECC.  If naively implemented, it
means that it takes twice longer time.  We would need to use twice
better (performance wise) chip for Gnuk Token.  Well, those
cryptographic computations could be done in parallel, so more cores or
more chips can be used.

I have been looking around the MCU chips for more cores.  IIUC, the
bandwidth of flash memory is one of major limitations.  If more cores,
better cache mechanism is needed.  But... having cache to the code means
that we need to consider side-channel attack.

GD32F103 or GD32VF103 runs on SRAM (or no-wait cycle flash).  If
something like GD32F103/GD32VF103 with multiple cores, it's promising.


(2) Space

PQC requires more memory.  Memory size would be no problem, but the size
in communication matters.  USB communication itself has no problem, but
I'm afraid that it's a bit difficult to keep using smartcard
interface/abstraction.


BTW, I'll join Debconf23.

Happy Hacking,
--