linux-kernel - Re: sysfs attrs for HW ECDSA signature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 Apr 2019 11:23:19 +0200
From:   Marek Behun <marek.behun@....cz>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: sysfs attrs for HW ECDSA signature

On Tue, 30 Apr 2019 10:27:28 +0200
Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:

> On Mon, Apr 29, 2019 at 11:47:52PM +0200, Marek Behun wrote:
> > Hi Greg and Tejun,
> > 
> > is it acceptable for a driver to expose sysfs attr files for ECDSA
> > signature generation?  
>
> What is "ECDSA signature generation"?  Is it a crypto thing?  If so, why
> not use the crypto api?  If not, what exactly is it?

Hi Greg,
It is a crypto thing and it should be accessed via akcipher crypto API.
But akcipher userspace crypto API is not implemented in kernel. See
below.

> > The thing is that
> >   1. AFAIK there isn't another API for userspace to do this.
> >      There were attempts in 2015 to expose akcipher via netlink to
> >      userspace, but the patchseries were not accepted.  
> 
> Pointers to that patchset?  Why was it not accepted?

Here are the replies to the last attempt
https://marc.info/?t=150234726200004&r=1&w=2
This was back in 2017, apparently there were some problems and it was not
merged even after 8 versions.

> >   2. even if it was possible, that specific device for which I am
> >      writing this driver does not provide the ability to set the
> >      private key to sign with - the private key is just burned during
> >      manufacturing and cannot be read, only signed with.  
> 
> Why does this matter?

If it was implemented via akcipher, the user would be unable to set
private key, which is a method the akcipher implementation should
implement. But this probably is not that big a problem.

> > The current version of my driver exposes do_sign file in
> > /sys/firmware/turris_mox directory.
> > 
> > Userspace should write message to sign and then can read the signature
> > from this do_sign file.  
> 
> How big are messages and signatures?  Why does this have to be a sysfs
> api?

Messages are 521 bits, I rounded them to 68 bytes. The idea is that a
sha512 hash of the original message is to be signed.
Signatures are 136 bytes.

> > According to the one attr = one file principle, it would be better to
> > have two files: ecdsa_msg_to_sign (write-only) and ecdsa_signature
> > (read-only).
> > Would this be acceptable in the kernel for this driver?  
> 
> Why not use the crypto api, and if that doesn't work, why not just a
> char device to read/write?

Because the akcipher userspace crypto API is not merged and it probably
will take a lot of time, if it ever will be merged. Till then I would
like if this feature was supported on this one device somehow in
mainline kernel. As soon as akcipher userspace crypto API is merged, I
can rewrite the driver.

A char device to read/write would be possible. The sysfs API
seemed more strainthforward. Should I do the char device approach
instead?

> > I have also another question, if you would not mind:
> > 
> > This driver is dependant on a mailbox driver I have also written
> > ("mailbox: Add support for Armada 37xx rWTM mailbox"), but I have not
> > received any review for this driver from the mailbox subsystem
> > maintainer, and I have already sent three versions (on 12/17/2018,
> > 03/01/2019 and 03/15/2019).
> > What should I do in this case?  
> 
> Poke the maintainer again :)

I will,

Thanks.

Marek