We have put significant resource into narrowing the attack surface of our device fleets, including the implementation of HSM type security/crypto modules to manage device secrets and PKI duties.
The mender client is the sole component of our stack unable to leverage these security resources, where, as the highest risk vector for attacking our fleet, the OTA updating service should actually provide features supporting the highest level risk mitigation.
Is there any intention to include HSM support in the client roadmap?
Hi @SuicidalLabRat, we do not have short-term plans to add HSM support on the client.
With that said, it is a feature we are aware and it is a matter of priorities and demand. One can always take a look at speeding up features based on our profession services offerings or if something like this would come as a community contribution that would also (obviously :)) speed it up.
I am curious what type of HMS are you using? Is it something like this,
Indeed. That is the exact chip we use. It enables all our mutual authentication, signing and secure boot functionality.
Can you point me at the code currently handling menders auth and signature validation? Assuming its contained/modular enough to be reviewed with relative ease.
A good place to start is probably here,
Just wanted to put my +1 here for this feature. We (like I’m sure many) are moving to using PKCS11 hardware to secure our AWS private keys. Usually, we use the same private key for both AWS and mender. It would be nice once we make this transition to have mender also move to make use of the PCKS11 hardware as well so that we don’t have to maintain two sets of keys (one secured in hw, one on the filesystem for mender). Much like @SuicidalLabRat said, it would be odd if our application is going to be more secure than the mechanism that updates the entire system image.
Thank you for the feedback, it is very valuable to us when planing new development.
Also @drewwestrick, which hardware are you using? Is it the same from Microchip mentioned above?
I have little experience working with HMS, and would be happy if you can share any information how you are using these hardware modules, what software stack to access them and how you incorporate them in your application.
Yes, @mirzak, we are planning on using the ATECC608A as well. To use the device, we will need to integrate the device driver, cryptoauthlib, which makes use of PKCS11 as an interface. It will also make sense to install gnutls on the debug device to test things out. Below are a few relevant yocto layers I plan on using:
The wiki from Microchip also gives some additional information on the device and driver installation. To test the hardware, I’m planning on getting a secure4click module for my SOM1 development kit.
Finally, I do know that AWS Greengrass does have support for PKCS11 URIs. I’m not sure what they are doing under the hood to support PKCS11 but I was going to poke around and see how they are using it to provide public private key authentication for their services. If I continue to make progress on this, I will definitely provide you with updates.
1 Like
Thank you. Highly appreciated.
I’m planning on getting a secure4click module for my SOM1 development kit.
I actually have the secure4click sitting on my desk, but never find the time to try it out.
@drewwestrick Note,that cryptoauthlib recipe isnt building the pkcs11 branch, which didnt exist when Digi published that bb.
Also note, the gnutls build may need to have p11-kit enabled via PACKAGECONFIG to get p11tool built.
SLR-
@SuicidalLabRat, Thanks for the heads up. I honestly haven’t really started any of this work yet. Much like @mirzak, I’m hoping to have some time to put toward this effort soon.
Note there has been some progress on this recently in the Mender client. Check out the following:
This is great news!
Thanks for the update.
SLR-
Just saw that pkcs11 support made it into Mender 2.5. I’d like to say thanks to Torben Hohn and the mender team for getting this put in. This is a great feature add and has the potential to improve device security and provisioning a ton.
Hear, hear! The OTA system is our most vulnerable vector for attack, and this addition will allow us to shore that up by moving related secrets to our onboard HSM.
This is a stand out feature for Mender, something I see as crossing a major delimiting point in their offering.
1 Like
Thanks for the kind words, I’m glad it’s appreciated! I believe @merlin and @oleorhagen deserve most of the praise for the actual work!
1 Like
Kudos to all involved!
2 Likes
Hi,
Thanks for all the great work you guys do !
Is there any plan to support HSM artifact signing with mender-artifact tool for standalone usages ?
1 Like
Is there any plan to support HSM artifact signing with mender-artifact tool for standalone usages ?
There is a ticket for it, [MEN-3163] - Mender and CFEngine (by Northern.tech) Jira but not much movement on that one.
Hello, everyone.
I am hijacking this thread, in order to ask a question about HSM and their use:
Now, that we are finishing the C++ client rewrite, I am implementing the HSM PKCS#11 support.
For now, this is limited to our Kirkstone branch, which has OpenSSLv3. As such, we are only supporting the new Provider API as such.
I have a couple of questions here:
How are you guys currently loading your providers. When implementing this now, I went for explicitly loading the provider from code:
As opposed to having the ssl config do it, like you are probably used to.
Please let me know if this is/will be an issue for anyone, and I will change it. But for now, this is the path I went down.
As far as I can tell, you can still override the provider with your config. But of course, I’m no expert here. As opposed to you guys 
