[PATCH] swupdate_class: Add support for engine signing

[George McCollister]

Add support for hardware signing of the SWU image via openssl engine

SWUPDATE_SIGNING_ENGINE will be used as the engine if it is set

SWUPDATE_SIGNING_ENGINE_PATH will be passed to openssl as
OPENSSL_ENGINES if set.

Signed-off-by: George McCollister <george.mc...@gmail.com>
---
README | 27 +++++++++++++++++++++++++++
classes/swupdate.bbclass | 22 ++++++++++++++++++++--
2 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 85faf8f..ad95902 100644
--- a/README
+++ b/README
@@ -31,6 +31,33 @@ sw-description.sig which is included in the SWU file.
Encrypted private keys are not currently supported since a secure
mechanism must exist to provide the passphrase.

+SWU image hardware signing
+--------------------------
+
+One may prefer to sign the SWU image with a hardware token or hardware security
+module (HSM) which doesn't expose the private key.
+
+To enable, SWUPDATE_SIGNING_ENGINE must be set to an available openssl engine.
+
+Example:
+ SWUPDATE_SIGNING_ENGINE = "pkcs11"
+
+SWUPDATE_SIGNING_ENGINE_PATH may need to be set so that openssl can locate the
+engine.
+
+Example:
+ SWUPDATE_SIGNING_ENGINE_PATH = "/usr/lib"
+
+Instead of setting SWUPDATE_PRIVATE_KEY to the full path of a file, set it to
+a key string recognized by the engine used.
+
+Example:
+ SWUPDATE_PRIVATE_KEY = "pkcs11:model=SoftHSM%20v2;" \
+ "manufacturer=SoftHSM%20project;" \
+ "serial=1234567890;" \
+ "token=test-token;pin-value=123456;" \
+ "object=swupdate-test"
+
Maintainer
----------

diff --git a/classes/swupdate.bbclass b/classes/swupdate.bbclass
index 5ef2ad8..dd1b526 100644
--- a/classes/swupdate.bbclass
+++ b/classes/swupdate.bbclass
@@ -144,16 +144,34 @@ python do_swuimage () {
privkey = d.getVar('SWUPDATE_PRIVATE_KEY', True)
if not privkey:
bb.fatal("SWUPDATE_PRIVATE_KEY isn't set")
- if not os.path.exists(privkey):
+
+ engine = d.getVar('SWUPDATE_SIGNING_ENGINE', True)
+ if engine:
+ engine = "-engine '%s' -keyform engine " % (engine)
+ elif not os.path.exists(privkey):
bb.fatal("SWUPDATE_PRIVATE_KEY %s doesn't exist" % (privkey))
+ else:
+ engine = ""
+
+ engine_path = d.getVar('SWUPDATE_SIGNING_ENGINE_PATH', True)
+ if engine and engine_path:
+ engine_path = 'OPENSSL_ENGINES="%s" ' % (engine_path)
+ else:
+ engine_path = ""
+
passout = d.getVar('SWUPDATE_PASSWORD_FILE', True)
if passout:
passout = "-passin file:'%s' " % (passout)
else:
passout = ""
- signcmd = "openssl dgst -sha256 -sign '%s' %s -out '%s' '%s'" % (
+
+ # Sign with openssl.real, provided by openssl-native so OPENSSL_ENGINES
+ # can be overridden
+ signcmd = "%sopenssl.real dgst -sha256 -sign '%s' %s%s -out '%s' '%s'" % (
+ engine_path,
privkey,
passout,
+ engine,
os.path.join(s, 'sw-description.sig'),
os.path.join(s, 'sw-description'))
if os.system(signcmd) != 0:
--
2.11.0

[Stefano Babic]

Hi George,

On 23/01/2017 17:18, George McCollister wrote:
> Add support for hardware signing of the SWU image via openssl engine
>

This is absolutely a good idea.

I have some questions because, apart of the patch, I have not well
understood how it works. I would like to test your patch on my own.

It will be nice to add a chapter in SWUpdate's documentation with a
simple HowTo for this.

> SWUPDATE_SIGNING_ENGINE will be used as the engine if it is set
>

Ok, so this is the name of the engine. But checking in openssl
documentation, I understand that the engine should be "dynamic", passing
with -pre the full path of the engine shared library.

So something as -pre SO_PATH /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH:<path to shared library for HW>

I see you have used softhsm2, it can be a good use case - that means we
should have something (check on Ubuntu):

-pre SO_PATH /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH:/usr/lib/x86_64-linux-gnu/softhsm/libsofthsm2.so


But I do not see the same in the patch. I propose you add also an
introduction with the required packages.

Another point is that the engine library (in this case, libsofthsm2.so)
is not built by Yocto, that is is not coming from a native recipe, but
it is the library installed on the host, and this is quite against
Yocto's philosophy.

Another question: do you have tested with some hardware token, too ? Can
you tell us which one ?

> SWUPDATE_SIGNING_ENGINE_PATH will be passed to openssl as
> OPENSSL_ENGINES if set.
>

So is the the full patrh of the shared library provided by the engine ?

Maybe the answer to most of my question resides in this for me cryptical
setup. Do you have a link (I guessed it is a setup for softhsm2, but I
have not found an explanation for it in softhsm2's doc).

Best regards,
Stefano

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[George McCollister]

On Wed, Feb 1, 2017 at 3:39 AM, Stefano Babic <sba...@denx.de> wrote:
> Hi George,
>
>
> On 23/01/2017 17:18, George McCollister wrote:
>> Add support for hardware signing of the SWU image via openssl engine
>>
>
> This is absolutely a good idea.
>
> I have some questions because, apart of the patch, I have not well
> understood how it works. I would like to test your patch on my own.
>
> It will be nice to add a chapter in SWUpdate's documentation with a
> simple HowTo for this.
>
>> SWUPDATE_SIGNING_ENGINE will be used as the engine if it is set
>>
>
> Ok, so this is the name of the engine. But checking in openssl
> documentation, I understand that the engine should be "dynamic", passing
> with -pre the full path of the engine shared library.

The openssl documentation covering the use of engines is pretty
incomplete. When using the pkcs11 engine (the most common case for
hardware signing) on systems with p11-kit properly configured you
don't want to use dynamic or specify the module path. p11-kit will
determine the correct module to use automatically. Some guides will
tell you to change your openssl.cnf file but this isn't required if
everything is configured correctly.

See the README here:
https://github.com/OpenSC/libp11

>
> So something as -pre SO_PATH /usr/lib/ssl/engines/libpkcs11.so
> MODULE_PATH:<path to shared library for HW>
>
> I see you have used softhsm2, it can be a good use case - that means we
> should have something (check on Ubuntu):

SoftHSM is basically an HSM emulator. It's not a proper HSM and isn't
any more secure than storing keys on your file system, but anyone can
install and test with it for free.

>
> -pre SO_PATH /usr/lib/ssl/engines/libpkcs11.so
> MODULE_PATH:/usr/lib/x86_64-linux-gnu/softhsm/libsofthsm2.so
>
>
> But I do not see the same in the patch. I propose you add also an
> introduction with the required packages.
>
> Another point is that the engine library (in this case, libsofthsm2.so)
> is not built by Yocto, that is is not coming from a native recipe, but
> it is the library installed on the host, and this is quite against
> Yocto's philosophy.

This is an issue I toiled over for quite some time. And to be honest I
never really found a solution which completely satisfied me.

Engines or engine modules often run a daemon which communicates with
the signing hardware. Either bitbake/OE would need to run the daemon
(there's nothing in place to support this) or libraries would need to
be built under OE and configured to communicate with a daemon running
outside of OE.

If softhsm was built under OE it would look for it's configuration and
database within sysroot. This wouldn't work since it wouldn't be
persistent so it would have to be changed to use a config and database
outside of OE or install existing ones.

Vendors of higher end HSMs usually only provide binaries and often do
so in a manner which makes them nearly impossible to fetch from a
recipe. It would be much easier to use these if they were configured
outside OE.

AFAIK the openssl engine API is stable and engine modules built for
the current version should continue to work new version of openssl.
Maybe there could be a problem if the engine used a shared library and
an incompatible version was found in sysroot (if nothing is found it
would use the libraries on the host and work fine).

>
> Another question: do you have tested with some hardware token, too ? Can
> you tell us which one ?
>

Nitrokey Pro works great for simple use cases. Generating keys and
backing them up without ever exposing them requires a more expensive
solution.
https://www.nitrokey.com/products/nitrokey-pro

YubiKey might work but I haven't used it.

>
>> SWUPDATE_SIGNING_ENGINE_PATH will be passed to openssl as
>> OPENSSL_ENGINES if set.
>>
>
> So is the the full patrh of the shared library provided by the engine ?

No, the directory openssl searches for the engine.
Usually /usr/lib, /usr/lib/engines, /usr/lib/openssl/engines or
something like that.

I've found documentation on almost everything related to this patch to
be a mix of scattered, incomplete, incorrect and out of date. Here are
some links:
https://wiki.opendnssec.org/display/SoftHSMDOCS/SoftHSM+Documentation+v2
https://github.com/OpenSC/libp11/blob/master/README.md
https://raymii.org/s/articles/Get_Started_With_The_Nitrokey_HSM.html

[Stefano Babic]

Hi George,

On 23/01/2017 17:18, George McCollister wrote:

Applied to -master, -morty, -krogoth, thanks !

Best regards,
Stefano Babic

[Stefano Babic]

Hi George,

I applied the patch, but I wanted to test myself, too. So I bought a
Nitrokey Pro as you suggested as compatible hardware.

I am able to sign sw-description, but not with openSSL as your patch
suggested. Because it does not worked in my case,I have tried first
outside Yocto build to check deeply.

Keys are on the Nitrokey (stored with gpg), I can see them with :

stefano@papero:~/Projects/swupdate$ pkcs15-tool --list-keys
Using reader with a card: Nitrokey Nitrokey Pro
(000032DF0000000000000000) 00 00
Private RSA Key [Signature key]
Object Flags : [0x3], private, modifiable
Usage : [0x20C], sign, signRecover, nonRepudiation
Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local
ModLength : 1024
Key ref : 0 (0x0)
Native : yes
Auth ID : 01
ID : 01
MD:guid : {b0adf255-dfbe-f6fb-b5db-ca17bcbd1322}
:cmap flags : 0x0
:sign : 0
:key-exchange: 0

Private RSA Key [Encryption key]
Object Flags : [0x3], private, modifiable
Usage : [0x22], decrypt, unwrap
Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local
ModLength : 1024
Key ref : 1 (0x1)
Native : yes
Auth ID : 02
ID : 02
MD:guid : {e90be326-0ff4-c2fd-67d6-90c8d43884f1}
:cmap flags : 0x0
:sign : 0
:key-exchange: 0


Fine. And if I can sign with:

pkcs11-tool -s -m SHA256-RSA-PKCS -o sw-description.sig -i sw-description

everything is still fine (but I am not using openssl as I wanted..), and
SWUpdate can verify successfully:

[NOTIFY] : SWUPDATE running : [parse_images] : Found Image :
core-image-full-cmdline-beaglebone.ext3 in device : /dev/mmcblk0p2 for
handler raw

[NOTIFY] : SWUPDATE running : [parse_scripts] : Found Script: test.lua

[NOTIFY] : SWUPDATE running : [swupdate_verify_file] : Verify signed
image: Read 428 bytes

[NOTIFY] : SWUPDATE running : [swupdate_verify_file] : Verified OK

I am maybe not setting correctly SWUPDATE_PRIVATE_KEY, but it looks also
that the library engine_pkcs11.so is not loaded if it is not part of
openssl.cnf.

Can you please share your setup and tell us how it works in your case ?
I do not think my test is a solution, because this also means to switch
to tools external to the Yocto build.

My last goal will be to add more detailed documentation for it, and to
put it inside the documentation for the project instead of in meta-swupdate.

Thanks,
Stefano

--
Meet DENX at the Embedded World Trade Show
14 Mar - 16 Mar 2017, Nuremberg Trade Fair Centre, Hall 4, Booth 581

[George McCollister]

On Sun, Mar 5, 2017 at 10:36 AM, Stefano Babic <sba...@denx.de> wrote:
> Hi George,
>

Make sure you have these installed (names could vary by distro):
libp11 (provides pkcs11 engine)
p11-kit (recommended to simplify setup)
opensc (for smartcards and smartcard like USB devices)

p11-kit makes it so you don't need to make any modifications to your
openssl.cnf file.
Make sure an opensc module file is installed (if the above packages
don't install it, you make need to create it yourself). On my system
it is located at:
/usr/share/p11-kit/modules/opensc.module
And contains "module: opensc-pkcs11.so"

Using p11tool to get the token URL:

Depending on system configuration, gpg-agent may need to be killed first.

$ p11tool --provider /usr/lib/opensc-pkcs11.so --list-tokens
Token 0:
URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29
Label: OpenPGP card (User PIN (sig))
Type: Hardware token
Manufacturer: ZeitControl
Model: PKCS#15 emulated
Serial: 000xxxxxxxxx
Module: (null)


Token 1:
URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%29
Label: OpenPGP card (User PIN)
Type: Hardware token
Manufacturer: ZeitControl
Model: PKCS#15 emulated
Serial: 000xxxxxxxxx
Module: (null)

Use the URL of the token to list the private keys:

$ p11tool --login --provider /usr/lib/opensc-pkcs11.so --list-privkeys \
"pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29"
Token 'OpenPGP card (User PIN (sig))' with URL
'pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29'
requires user PIN
Enter PIN:
Object 0:
URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29;id=%01;object=Signature%20key;type=private
Type: Private key
Label: Signature key
Flags: CKA_PRIVATE; CKA_NEVER_EXTRACTABLE; CKA_SENSITIVE;
ID: 01

Use the URL for SWUPDATE_PRIVATE_KEY. You can append
";pin-value=123456" to prevent it from prompting you for the PIN.

SWUPDATE_SIGNING = "1"
SWUPDATE_PRIVATE_KEY =
"pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29;id=%01;object=Signature%20key;type=private;pin-value=123456"
SWUPDATE_SIGNING_ENGINE = "pkcs11"
SWUPDATE_SIGNING_ENGINE_PATH = "/usr/lib"

To manually sign with openssl you can do something like this:
openssl dgst -engine pkcs11 -sha256 -sign
"pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29;id=%01;object=Signature%20key;type=private"
-keyform engine -out sw-description.sig sw-description

I also added pkcs11 signing support to u-boot's mkimage. For more
information see detailed instructions under "Hardware Signing with
PKCS#11" here:
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/signature.txt

I also found this to be a helpful reference:
https://github.com/OpenSC/libp11/blob/master/README.md

Let me know if you still run into problems.

>
> My last goal will be to add more detailed documentation for it, and to
> put it inside the documentation for the project instead of in meta-swupdate.

Where in the documentation would be a good place to add it? I may be
able to submit a patch at some point. We probably only be able to
provide some examples of the setup as the configuration can vary by
distro and the hardware token/module used.

[Stefano Babic]

Hi George,

I missed these two packages, thanks.

Thanks - much clearer now.

> I also added pkcs11 signing support to u-boot's mkimage. For more
> information see detailed instructions under "Hardware Signing with
> PKCS#11" here:
> http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/signature.txt
>

Thanks again - I missed your patches, you had already explained this in
u-boot.

> I also found this to be a helpful reference:
> https://github.com/OpenSC/libp11/blob/master/README.md
>
> Let me know if you still run into problems.

Rather there are problems due to the fact that openssl.real (openssl
native, built by Yocto) does not have pkcs11, and the versions are not
compatible (this is saying the log). In fact, I have errors when image
is signed:

invalid engine "pkcs11"
139650463065752:error:25066067:DSO support routines:DLFCN_LOAD:could not
load the shared
library:dso_dlfcn.c:187:filename(/usr/lib/ssl/engines/libpkcs11.so):
/work/stefano/db-morty-twister/tmp/sysroots/x86_64-linux/usr/bin/../lib/libcrypto.so.1.0.0:
version `OPENSSL_1.0.0' not found (required by
/usr/lib/ssl/engines/libpkcs11.so)

The question is if openSSL is loading the correct library. It looks
there is a conflict (what Yocto tries to avoid, we are now forcing the
behaviour) because the built openSSL in morty not fully compatible with
libpkcs11 (if my system has loaded the correct library).

On a Ubuntu Distro, after installing the packages, I see the following
libraries:

/usr/lib/ssl/engines/libpkcs11.so
/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so

The first one is loaded passing "pkcs11" as engine - openssl search for
a "libpkcs11". Anyway, openssl does not provide a recursive search, so
on Ubuntu :
SWUPDATE_SIGNING_ENGINE_PATH = "/usr/lib/ssl/engines"

The second one is loaded by p11-kit, where everything works fine (I get
token, URL, .. - but I us ethe distro tools).

>
>>
>> My last goal will be to add more detailed documentation for it, and to
>> put it inside the documentation for the project instead of in meta-swupdate.
>
> Where in the documentation would be a good place to add it? I may be
> able to submit a patch at some point. We probably only be able to
> provide some examples of the setup as the configuration can vary by
> distro and the hardware token/module used.

I have intentionally omitted at the beginning some documentation about
meta-swupdate, with the idea to put this doc inside meta-swupdate repo.
Anyway, it looks to me a better idea to put this in the documentation
for the project. Currently, the explanation about all SWUPDATE_
variables, how to add own scripts, how to build a signed sw-description
is missing.

In swupdate.rst there is a chapter "Building with Yocto". This must be
improved, and I thought that the description for the hardware key (as
you have already added to U-Boot) can be added here in a subchapter.

Best regards,
Stefano

[George McCollister]

Which distro and distro version are you using here? I'd like to take a
look at the packages to see what is going on. It seems odd it would
complain about `OPENSSL_1.0.0' not found since morty uses openssl
1.0.x.

Sounds like a good plan.

[Stefano Babic]

Hi George,

This is Ubuntu 16.04.2 LTS

The only way I have found to overcome the problem is to switch to
pkcs11-tool. The following line generates the signature:

pkcs11-tool -s -m SHA256-RSA-PKCS -o sw-description.sig -i sw-description

(Until I have just a hard key in system, there is no need of additional
parameters).

But it flawlessly works even with distro openssl - but not with the
generated openssl.real :-(

[George McCollister]

Did it work out of OE with openssl from Ubuntu? If not you need to
troubleshoot this first.

[Stefano Babic]

Hi George,

It works, but not with OPENSSL_ENGINE - instead, I get working following
the instructions here:

https://github.com/OpenSC/OpenSC/wiki/Quick-Start-with-OpenSC#testing-using-openssl


stefano@papero:~/Projects/swupdate/hardkey$ openssl
OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so
-pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:opensc-pkcs11.so
Loaded: (pkcs11) pkcs11 engine
OpenSSL> dgst -sha256 -sign
'pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=0005000032df;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29;id=%01;object=Signature%20key;type=private'
-engine 'pkcs11' -keyform engine -out
'/work/stefano/db-morty-twister/tmp/work/twister-poky-linux-gnueabi/update-image/1.0-r0/update-image/sw-description.sig'
'/work/stefano/db-morty-twister/tmp/work/twister-poky-linux-gnueabi/update-image/1.0-r0/update-image/sw-description'
engine "pkcs11" set.
PKCS#11 token PIN:
OpenSSL> quit


Regards,

[George McCollister]

If you have to do this p11-kit probably isn't setup correctly.

[Stefano Babic]

Hi George,

On 08/03/2017 18:25, George McCollister wrote:

>>>>>>>> pkcs11-tool -s -m SHA256-RSA-PKCS -o sw-description.sig -i sw-description
>

> If you have to do this p11-kit probably isn't setup correctly.

I do not see the same. If p11-kit was wrongly installed or configured, I
could not sign with the pkcs11-tool, but I can. And openssl works
exactly in the way explained on the NitroKey website and in the opensc
documentation.

IMHO the big issue is the mix between distro tools and native tools
built by Yocto. Even if this could work on some distros or with some
versions of the distros, we cannot be always be sure about this.
security update provided by distro can break the build again - it seems
to me unreliable.

I think it is better to rely on the same set of tools, avoiding any kind
of mix. The distro provide tools working in the distro, and Yocto builds
tools working in the build (the native tools) or as SDK (nativesdk). If
we do not mix them, it works.

My suggestion is to get rid of switches for openssl, and to provide the
whole command for sign. So instead of SWUPDATE_SIGNING_ENGINE,
SWUPDATE_SIGNING_ENGINE_PATH and SWUPDATE_PRIVATE_KEY (in case of hard
key), we can have something like:

SWUPDATE_SIGN_TOOL="OPENSSL_ENGINES=..... /usr/bin/openssl dgst ...."

or

SWUPDATE_SIGN_TOOL="pkcs11-tool -s -m SHA256-RSA-PKCS -o
sw-description.sig -i sw-description"

or

..... something else.

This seems to me an easier a more clearer solution, and everybody can
use whatever he has (even a proprietary tool), if it provides signing
according to standard.

Best regards,
Stefano

[George McCollister]

On Thu, Mar 9, 2017 at 2:01 AM, Stefano Babic <sba...@denx.de> wrote:
> Hi George,
>
> On 08/03/2017 18:25, George McCollister wrote:
>
>>>>>>>>> pkcs11-tool -s -m SHA256-RSA-PKCS -o sw-description.sig -i sw-description
>>
>> If you have to do this p11-kit probably isn't setup correctly.
>
> I do not see the same. If p11-kit was wrongly installed or configured, I
> could not sign with the pkcs11-tool, but I can. And openssl works
> exactly in the way explained on the NitroKey website and in the opensc
> documentation.

pkcs11-tool --help shows that opensc-pkcs11.so is the default module
if none is specified. This could explain how pkcs11-tool could be
working without p11-kit.

>
> IMHO the big issue is the mix between distro tools and native tools
> built by Yocto. Even if this could work on some distros or with some
> versions of the distros, we cannot be always be sure about this.
> security update provided by distro can break the build again - it seems
> to me unreliable.

Agreed. It can be quite a mess.

>
> I think it is better to rely on the same set of tools, avoiding any kind
> of mix. The distro provide tools working in the distro, and Yocto builds
> tools working in the build (the native tools) or as SDK (nativesdk). If
> we do not mix them, it works.
>
> My suggestion is to get rid of switches for openssl, and to provide the
> whole command for sign. So instead of SWUPDATE_SIGNING_ENGINE,
> SWUPDATE_SIGNING_ENGINE_PATH and SWUPDATE_PRIVATE_KEY (in case of hard
> key), we can have something like:
>
> SWUPDATE_SIGN_TOOL="OPENSSL_ENGINES=..... /usr/bin/openssl dgst ...."
>
> or
>
> SWUPDATE_SIGN_TOOL="pkcs11-tool -s -m SHA256-RSA-PKCS -o
> sw-description.sig -i sw-description"
>
> or
>
> ..... something else.
>
> This seems to me an easier a more clearer solution, and everybody can
> use whatever he has (even a proprietary tool), if it provides signing
> according to standard.

Sounds like a better idea but will we break compatibility with the old method?

Maybe we should:
Remove SWUPDATE_SIGNING_ENGINE_PATH, SWUPDATE_SIGNING_ENGINE.
Keep SWUPDATE_SIGNING, SWUPDATE_PRIVATE_KEY, SWUPDATE_PASSWORD_FILE.
Add SWUPDATE_SIGN_TOOL. If SWUPDATE_SIGNING and SWUPDATE_SIGN_TOOL it
is set, SWUPDATE_SIGN_TOOL is used instead and SWUPDATE_PRIVATE_KEY,
SWUPDATE_PASSWORD_FILE are ignored.

If you're not concerned with keeping compatibility we can get rid of
SWUPDATE_PRIVATE_KEY and SWUPDATE_PASSWORD_FILE as well.

I'll be happy to make the changes and submit a patch to clean this up
since I created the mess.

[Stefano Babic]

Hi George,

Right, I see the same.

> Keep SWUPDATE_SIGNING, SWUPDATE_PRIVATE_KEY, SWUPDATE_PASSWORD_FILE.

Right.

> Add SWUPDATE_SIGN_TOOL. If SWUPDATE_SIGNING and SWUPDATE_SIGN_TOOL it
> is set, SWUPDATE_SIGN_TOOL is used instead and SWUPDATE_PRIVATE_KEY,
> SWUPDATE_PASSWORD_FILE are ignored.

Agree.

>
> If you're not concerned with keeping compatibility we can get rid of
> SWUPDATE_PRIVATE_KEY and SWUPDATE_PASSWORD_FILE as well.

No, this is a use case. If someone does not have or does not use a
hardware key, the only way is with a file. This should remain.

>
> I'll be happy to make the changes and submit a patch to clean this up
> since I created the mess.

Well, then I wait for your patch... :-)

Best regards,

Stefano


--
Meet DENX at the Embedded World Trade Show
14 Mar - 16 Mar 2017, Nuremberg Trade Fair Centre, Hall 4, Booth 581