Using an HSM (PKCS#11) with Leshan client for LwM2M bootstrap over DTLS

[fbattello]

Question

Let’s assume a device with an HSM, running the Leshan client.
Haven't found any mention of HSM/PKCS#11 integration in the Leshan project (for the client side), neither in the documentation nor in the examples.
It seems that Scandium does support PKCS#11, according to comments in the class PskStore.

Do you think it's feasible and what would be the best approach to achieve that ?

[sbernard31]

Could you describe what you delegate to HSM ?
(a kind of high level description of input/ouput sent to your "blackbox" HSM)

[fbattello]

I would like to delegate to HSM the crypto operations needed by the DTLS handshake.

[jvermillard]

I suppose you wan to us RPK or X509? Because I don't think it would be doable for PSK

[fbattello]

Damn, I was thinking about PSK.
For which reason do you think it would be doable for RPK/X509 but not for PSK ?
Is it a matter that Scandium not supporting PSK ?

[sbernard31]

I would like to delegate to HSM the crypto operations needed by the DTLS handshake.

Sorry I guess this is obvious to you but I expected a more precise description of your HSM usage.

Reading PskStore interface from Scandium, I understand that this can just be used to create masterkey from HSM.

But I'm a bit confused where will be store your Identity and your Preshared key ?

[fbattello]

The Preshared key is intended to be stored in the HSM and to remain confined in the HSM.
Don't know yet for its identity but it's kind of "public" information, maybe on disk.
As a first approach I'm just trying to figure out whether a Leshan client (together with Scandium) would allow to use PKCS11 (for the PSK case).

[jvermillard]

PKCS#11 is great for asymmetric keys (RSA/ECC): you generate the private key in the HSM and you never expose it outside.
For PSK you need to save the key in both the server and client, so your key is exposed, so that why I was assuming "HSM" means asymetrical crypto. I think you should clarify PSK/HSM support with the Californium project first (e.g. opening an issue).

Also, if you use PSK with LWM2M bootstrap the key is moving over the air so I'm not sure it make sense to use it with an HSM.

[fbattello]

My assumption is that the key is securely provisioned in the HSM then doesn't move over the air but used to solve whatever challenge from the server (e.g. sign some stuff at the end of the handshake).
I'll have a deeper look at Californium/Scandium (especially the SecretResult and SecretKey objects) and follow your advice : first ask Californium for PSK/HSM support confirmation.

[sbernard31]

As @jvermillard said, if you are using LWM2M bootstrap to setup PSK mode on client then PSK will be sent over the air. (This is just how LWM2M works)

And also shared-key must be known by client and server. So you will not be able to have the key only in client HSM. (at least you need a copy at server side)

Anyway,

As a first approach I'm just trying to figure out whether a Leshan client (together with Scandium) would allow to use PKCS11

I don't know so much PKCS11, I just ear about it via keystore feature provided by JCE. (but is seems this is much more than a keystore)
I understand that you just want to create the master key from public identity. Never tested but it seems to be possible with Scandium reading the code.

At Leshan client side, code was not designed for that use case.
Leshan client is using SinglePskStore.

org.eclipse.leshan.transport.californium.client.endpoint.coaps.CoapsClientEndpointFactory is responsible to create the PskStore.

In a first time you could just test to create your own/custom CoapsClientEndpointFactory and return your own implementation of PskStore.

But there is another issue (maybe a bigger one), currently Leshan client expect to get access to PSK and Identity via Security object. So you will need to kind of HACK to workaround that. Maybe providing a fake key here.... 😬

If you want a bootstrap server to be able to write new PSK credentials then you need to implement Security.write so key will be store in HSM. (Not that theoretically, you should also support to read secret key)
But again nothing is really think to support that.

If the use case makes sense and you have some idea to improve API, we can consider that.

[fbattello]

When you say “PSK sent over the air”, does it apply to Client initiated bootstrap (as well as Server initiated bootstrap) ?
In my case the setup is closer to Factory Bootstrap, i.e., the PSK is provisioned out-of-band from an LwM2M point of view.

My initial idea was : it would be nice to avoid storing raw PSK bytes and instead reference a non-exportable key in an HSM via PKCS#11, with the DTLS stack using it during PSK handshakes.
It could make sense depending on IoT increasing security requirements. As for now I understand that it can be feasible but the path might not be immediate (study interface with the Scandium DTLS stack, might require customer behavior implementation and some workarounds).

[sbernard31]

When you say “PSK sent over the air”, does it apply to Client initiated bootstrap (as well as Server initiated bootstrap) ?

Yep this is for Client and Server initiated Bootstrap.
(Not for Factory Bootstrap)