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

[Aurelien Jarno]

On 2017-10-17 09:07, NIIBE Yutaka wrote:
> 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.

Yes, at least the ChaosKey is using the Openmoko VID. As far as I know
they use the fact that they signed the agreement with USB-IF *before*
transfers or subassignments were prohibited. That's also how pid.codes
[0] offers PID to free software projects.

[0] http://pid.codes

> 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.

Do you think it would be possible to allow any PID with VID 6666 which
is for the prototype product vendor ID? It's of course not possible to
sell a device with such an ID, nor it would be possible for Debian to
distribute binaries with such an ID. On the other hand it's very useful
for personal use, and I use that for many of my other personal projects.

> >> 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.

Ok, thanks for the detail, I'll think about that.

> > 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.

Indeed, the side channel attacks on an embedded MCU and on a computer
are not necessarily the same (some of them are common). In the past it
seems PolarSSL was going towards the computer world, especially with
their OpenVPN-NL product. Now that Arm is behind the project, I guess
it's going again towards the embedded world.

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

One nice side effect of using a Cortex-M4 based MCU is that the
"multiply with 64-bit result" instructions are executed in constant time.

> That's the situation.
> 
> 
> The work for merging from/to upstream will be welcome as long as Gnuk on
> STM32F103 keep working great.

That's also my goal. I will do my best to ensure that, but mistake can
always happen. I also have some improvements in mind that may also
benefit the STM32F103.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien at aurel32.net                 http://www.aurel32.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/attachments/20171017/7363bb7f/attachment.sig>