LwM2M: engine doesn't support offloaded TLS stack

[mike-scott]

Is your enhancement proposal related to a problem? Please describe.
Right now, enabling LWM2M_DTLS_SUPPORT forces the use of TLS_CREDENTIALS lib which places credentials into RAM and is not really compatible with offloaded TLS stack where credentials will need to be sent to NCP.

Describe the solution you'd like
LwM2M subsys is a bit unique due to it's operation flow of "bootstrap" server loading the security information for next LwM2M servers. This data needs to be pulled from the loaded security object and fed into TLS credentials "on demand" by the engine.

Easiest solution (but probably not the best) would be a function pointer in the client context that could be set for loading credentials (as opposed to using tls_credential_add()).

Describe alternatives you've considered
A more complex solution would be adding hooks into the TLS credential subsystem itself for offloaded solutions. But this could be involved and mappings between credential types would need to be established on a per implementation basis, etc.

[mike-scott]

@rlubos @GAnthony @pfalcon There is some discussion to be had here for enhancing the TLS credential subsystem vs. putting in an LwM2M specific solution where the call to tls_credential_add() could be changed to something else.

[mike-scott]

add @jukkar for discussion

[rlubos]

I had it in the back of my head, that for offloaded solutions we might need to provide an alternative implementation of this API, which instead of keeping the credentials in RAM, would provision it into the offloaded engine.

But I think it's not only about offloaded solutions. Currently, we store the certificates/keys in RAM, which is not a safe approach. I've heard complaints about it, yet I haven't heard of any alternative proposal (I'm not even sure if there is an API for some kind of secure storage in Zephyr). Making it possible to provide alternative implementations at TLS credential subsystem level, would benefit for the native stack as well, allowing to hook up some secure storage in the future (or simply flash in case keys are provisioned run-time like in this case).

So personally, I think we should go in the direction of extending the TLS credential subsystem, especially that the API is pretty simple so it should not be a big effort. A vtable perhaps, defaulting to RAM implementation + API to update it to a custom one?

[GAnthony]

@vanti, FYI

One way we worked around this, for TI SimpleLink socket offload driver, we added a config option
CONFIG_TLS_CREDENTIAL_FILENAMES
which told the offload API to access credentials stored on secure flash by filename: eg:
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/sockets/http_get/src/ca_certificate.h
The credentials, in this case, are stored offline by a TI UniFlash tool.

But, ideally, would be good to have a Zephyr API that can store the credentials to Flash (as needed, eg, by OTA updates).