PSK and RPK support using `coap+tcp`

[sbernard31]

I have a first working version of coap+tcp in Leshan based on java-coap. (https://github.com/open-coap/java-coap/issues/69#issuecomment-1781460170) This is probably not production ready, especially about how connection is managed but this is good enough to be able to play with it.

So I tried to begin to look at adding coaps+tcp support. In LWM2M generally the first step is using Pre-shared Key. (Far easier to set-up than RPK or x509)

Naively, I was thinking that I will be able to set-up this quickly but I understand there is no Pre-Shared Key support in java-coap ? more exactly java-coap API is based on JSSE API (SSLSocketFactory more precisely) and I understand that PSK is not supported by the default SunJSSE Provider (default implementation of JSSE API) ... :disappointed:

Am I right or did I missed something ?

[szysas]

AFAIK JSSE still does not support PSK. There is library https://github.com/google/conscrypt that gives such support but it uses native BoringSSL.

[sbernard31]

AFAIK JSSE still does not support PSK.

:cry:

Even if this seems to be about TLS 1.3, JDK-8049402 is probably a hint that it is not supported.

There is library https://github.com/google/conscrypt that gives such support but it uses native BoringSSL.

Thx for sharing this. During my search about that I found it it too. I will keep it in mind. But I will try see if there is other alternative.

I will also look at Bouncy Castle.

[sbernard31]

@davidgraeff long time ago you try to add DTLSConnector to Scandium based on SSLEngine and you faced issues about PSK.

How end your story about that ? :slightly_smiling_face:

[sbernard31]

Talking with security-dev from OpenJDK, they confirm those features are not available :

• PSK,
• AES_CCM,
• RPK ,
• CID

So at short term I will focus on X509 only. At mid term, I don't know if this is worth to try to play with Concrypt or BouncyCastle :thinking: (without concrete user interest I guest not) At long term, OpenJDK developper seems to be open to contribution. I will see if this is realistic to try help to move this topic forward.

[davidgraeff]

@sbernard31 Thanks for asking, but that is indeed a long time ago. Sad that OpenJDK has no native implementations for necessary features

[szysas]

@sbernard31 do you see any real use case where PSK or RPK would be needed? What's the difficulty on setting up certificates? I see using of PSK very difficult, if we think of provisioning them to devices in secure way and then doing rolling updates.

[sbernard31]

@szysas good questions :slightly_smiling_face:

do you see any real use case where PSK or RPK would be needed?

For PSK :

I know for sure at least one :sweatsmile: at SemTech (previously Sierra Wireless), our LWM2M devices only use PSK. Note also that LWM2M v1.0.x : "A LwM2M Server MUST support the Pre-Shared Key mode"_ (since v1.1.x the wording is more flexible)

You can also find a list of known real use cases in RFC 9257 - Guidance for External Pre-Shared Key (PSK) Usage in TLS § 5.1. Use Cases.

Some known pro of PSK usage :

"The pre-shared key profile offers the most efficient solution for integration of TLS/DTLS into LwM2M since pre-shared ciphersuites recommended in [RFC7925] require a minimum amount of flash space as well as RAM size. Symmetric cryptographic algorithms require only a minimal computational overhead. The size of the exchanged messages is also kept at a minimum. There is, however, a downside as well: symmetric keys need to be pre-configured to both communication endpoints."

(source : LWM2M-v1.1.1@transport§5.2.8. Credential Types)

and

"The use of pre-shared secrets is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving."

(source : RFC7925 - (D)TLS Profiles for the Internet of Things § 4.2 Pre-Shared Secret

For RPK :

No real use case example in mind (like the SemTech one above :point_up_2: ) but this is real mode defined in LWM2M specification too.

Some known pro about RPK usage :

"The raw public key profile offers features that sit between the pre-shared key and the certificate-based profile and combines the benefits of these two profiles. The use of asymmetric cryptography offers improved security but avoids the overhead associated with certificates and the PKI."

(source : LWM2M-v1.1.1@transport§5.2.8. Credential Types)

"The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is the first entry point into public key cryptography without having to pay the price of certificates and a public key infrastructure (PKI)."

(source : RFC7925 - (D)TLS Profiles for the Internet of Things § 4.3 Raw Public Key)

What's the difficulty on setting up certificates?

I think there some points above to slightly explain why some could not want using certificates.

Note also that for some constraint device, supporting PSK or RPK could be lightweight or "easier". (when I was playing with tinyDTLS only PSK and RPK was available)

Deploying PKI based on Certificate is not so simple and in LWM2M client client authentication is required too. Also LWM2M v1.0.x has limited support of Certificate, this was improved with v1.1.x and even better with 1.2.x.

Even if I agree that "real use case" is the stronger argument, I also think that from a developer point of view PSK and RPK are good step in learning curve :

• first playing with plain coap (which should have very few real world use cases)
• then next step, testing with PSK (easier to just set login/password)
• then using RPK, you will face some new difficulty about understanding asymmetric cryptography (and also need to understand how to generate keys)
• then using x509 is even more complicated to understand with certificate chain and all possible way to validate it and also PKI infrastructure.

I see using of PSK very difficult, if we think of provisioning them to devices in secure way and then doing rolling updates.

I don't know exactly what you have in mind about rolling updates ?

At least in LWM2M there is a bootstrap mechanism which allow to provision the LwM2M Client with the information required to contact the LwM2M Server(s) but you could argue how to provision client credentials to connection to Bootstrap Server. :shrug:

Factory provisioning is still a very complex question. I'm not sure this is easier with X509 especially for LWM2M use cases which need client server mutual authentication.

[sbernard31]

(a bit out of topic but I have a first version of coaps+tcp with x509 support only in Leshan : https://github.com/eclipse-leshan/leshan/pull/1607)