[Gnuk-users] [PATCH 0/7] Gnuk: add support for Cortex M4 MCU

[NIIBE Yutaka]

Aurelien Jarno <aurelien at aurel32.net> wrote:
> I am fine with releasing my changes under GPLv3+, and I understand the
> agreement with USB-IF. Actually I fully understand it's not directly
> related to FSIJ and Gnuk, many hardware projects got the issue. Some
> projects had a more liberal usage of their VID than Gnuk (like giving
> or selling PID), and since then the USB-IF has been more strong to make
> sure everybody follows the agreement.

Thank you.

The condition of non-use of VID is _not_ by (the power of) copyright of
FSIJ.  FSIJ asks non-use of their VID, because of the agreement.  I
think that if it were based on copyright, it contradicts free software
license.

Yesterday, I was told about Openmoko Inc. [0]

[0] http://wiki.openmoko.org/wiki/USB_Product_IDs

IIUC, they can do that, because they no longer have plan to release
products any more.  Such "tranfer" (from my viewpoint) could have risk
of ban from USB-IF.  For assignee which distributes hardware products,
I think that it is not possible to do that.

Well, if someone will get PID from [0] and he will ask adding a line to
gnuk/GNUK_USB_DEVICE_ID, I won't have any reason to reject that.

>> Speaking about my own situation, once, I have said publicly that my code
>> should be 100% free software, always.  (I didn't expect I encounter such
>> a tricky situation.)  One of the reasons why I assign my work for Gnuk
>> to FSIJ is to keep sane myself. :-)
>
> From what I understand I don't have to assign my work for Gnuk to FSIJ,
> correct?

No, it's not the requirement for contributors, while I recommend
assignment to FSIJ.  I don't explicitly advertise the non-requirement.
When asked, I answer.

That's because... if excessively conservertive for the interpretation of
the agreement between USB-IF, it would be possible to interpret:
accepting any patches means virtually "transfer"ring something.

> When looking at the whole picture, Gnuk is using a very small subset of
> PolarSSL.

Yes.  AES and RSA.  And RSA is heavily modified.

> It might make sense to submit the MULADDC part to mbedTLS, especially
> now that the upstream has changed. However it depends on the changes you
> have done to directly use the pointers in the asm code instead of
> copying them first into registers. I'll see if I can find some spare
> time to do that.

Let's see.

As I wrote in the previous mail, mbedTLS adopted RSA blinding (base and
exponent).  I know that that's considered a best practice for RSA
implementation these days (against attacks), as we can see BSI (in
Germany) document.

Gnuk cares much on constant-time implementation of RSA, and not use
blinding.  When I talked to the upstream of mbedTLS, they didn't have
much interest on constant-time implementation of RSA, it seemed.

If someone really wants to use Gnuk on GNU/Linux, we need to replace
current RSA implementation.  Apparently, it's not safe against some sort
of side channel attacks on usual architecture.

Only for STM32F103, I do my best to be more constant-time ("more" means
it's not perfect).

That's the situation.


The work for merging from/to upstream will be welcome as long as Gnuk on
STM32F103 keep working great.
--