Key Missing Feature for IoT

[Daniel Jeliński]

Well I think AES-CCM is a decent candidate to start. If you choose to
work on this, you'll need to add support for AES/CCM to the JCE first.
Most of the code is already there: AES is implemented, CTR and CBC are
implemented, AEAD mode is implemented, so it's probably just a matter
of wiring these things together, and adding some known-answer tests,
which you can find here:
https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/CAVP-TESTING-BLOCK-CIPHER-MODES

Yes, you'll need the Oracle Contributor Agreement before you can
contribute code to the JDK. Once you have it, you can open a PR. Use
8176395 in the PR title. The guide contains the instructions for
running selected tests only.

Regarding PSK API, if you could put together a more complete proposal
of the API changes, together with an example of how this would look
from the API consumer side, this would be a good starting point for a
discussion. I know this is a lot to ask, but this is necessary to make
progres on the PSK.

Cheers,
Daniel

pt., 15 mar 2024 o 16:43 Simon Bernard <contact at simonbernard.eu> napisał(a):
>
> Thx for all this clarification.
>
>  For example, how will the user configure the list of available PSKs?
>
> Regarding PSK API from other libraries :
>
> AdvancedPskStore from Scandium 3.x which is not so straight forward to use mainly because it supports async request : https://github.com/eclipse-californium/californium/blob/3.11.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/AdvancedPskStore.java
>
> PskStore from Scandium 2.x is more simple to understand but no async way to request PSK : https://github.com/eclipse-californium/californium/blob/2.8.0/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/pskstore/PskStore.java
>
> PSKKeyManager from Concrypt is a more JSSE oriented API (no async too). I also understand that this API is available when coding for Android but I think there is a drawback a client is not able to select Identity based on InetSocketAddress of destination.
>  - https://android.googlesource.com/platform/frameworks/base/+/ba12af5/core/java/android/net/PskKeyManager.java
>  - https://github.com/google/conscrypt/blob/2.5.2/common/src/main/java/org/conscrypt/PSKKeyManager.java
> Note that this class is deprecated in concrypt : I tried to get more about this : https://github.com/google/conscrypt/issues/1197
>
> TlsPSKIdentityManager is very simple and very limited API from Bouncy Castle : https://github.com/bcgit/bc-java/blob/1.72/tls/src/main/java/org/bouncycastle/tls/TlsPSKIdentityManager.java
>
> Note that most of them would probably have been thought with (D)TLS 1.2 in mind. I don't know if this is adapted for (D)TLS 1.3.
>
> Well, for AES-CCM a pull request would have been nice :)
>
> I'm not so familiar with JSSE API/SunJSSE provider design for now. Do you think AES-CCM is a good candidate to start ?
> I guess if I want to try to help on this, I need to have a look at : https://openjdk.org/guide/ (and also Contribution agreement)
> Oh and working on JSSE when it's time to build/running tests is there a more simple way than building/testing whole JDK ?
>
> Simon
>
> Le 15/03/2024 à 13:16, Daniel Jeliński a écrit :
>
> Hi Simon,
> Yes, the cipher suites in CipherSuite class are available in both TLS
> and DTLS by default. TLS 1.3 uses different cipher suites from TLS
> 1.2, so both protocols need to be updated.
>
> Regarding backporting to other versions of Java, backports are
> reviewed on a case-by-case basis. TLS changes are usually backported,
> but that's not a given.
>
> RPK is not implemented either; we have a declaration for the relevant
> handshake extensions here:
> https://github.com/openjdk/jdk/blob/80ccc989a892e4d9f4e2c9395a100cfabbdcda64/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#L239-L240,
> but the producers and consumers aren't defined.
>
> Which kind of help do you need 🙂 ?
>
> Well, for AES-CCM a pull request would have been nice :)
> For the other topics, I think we'd need to agree on the scope of the
> API changes needed. For example, how will the user configure the list
> of available PSKs? Will we need an API change? If not, which of the
> available APIs will we use to configure the keys?
>
> Cheers,
> Daniel
>
>
>
>
> pt., 15 mar 2024 o 11:58 Simon Bernard <contact at simonbernard.eu> napisał(a):
>
> Hi Daniel,
>
> Thx for quick answer.
>
> For PSK and AES, if this is added then this will be also for TLS ? (not only DTLS  right ?) and for version 1.2 and 1.3 ? and also when this feature will be added, would they be available on next JDK version OR also old version ? (e.g. I know some recent security feature was backported in java8)
>
> Today, I was looking at Raw Public Key support (RPK) and I understand this is not supported too. Am I right ?
> RPK is also part of LWM2M specification and also refered in (RFC7925§Section4.3 - TLS / DTLS -Profiles for the Internet of Things) :
> "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)."
>
>  Help is welcome.
>
> Which kind of help do you need 🙂 ?
>
> Simon
>
> Le 15/03/2024 à 11:38, Daniel Jeliński a écrit :
>
> Hi Simon, welcome to security-dev!
>
> You got the situation of DTLS right:
> - PSK cipher suites were first requested in JDK-6476446, then in JDK-8049402.
> - connection identifier is not implemented, and not on the to-do list yet;
> - AES-CCM was requested in JDK-8008342, then in JDK-8176395. If I
> understand correctly, this one should be relatively easier to
> implement, using the implementation of the ChaCha20 cipher as an
> example (see JDK-8140466, JDK-8204192).
>
> It makes perfect sense to add these features to the OpenJDK. They were
> never high enough on the priority list to get implemented. Help is
> welcome.
>
> Cheers,
> Daniel
>
>
> czw., 14 mar 2024 o 17:31 Simon Bernard <contact at simonbernard.eu> napisał(a):
>
> Hi all,
>
> I'm the main Maintainer of Leshan. An open Source Java Implementation of LWM2M protocol.
>
> LWM2M is mainly based on coap and coap+tcp protocol.
> Security is available by usage of coaps and coaps+tcp which are based respectively on DTLS and TLS (mainly v1.2 for now)
>
> Currently we only have support of coap and coaps. We are using Scandium as DTLS implementation, this is an historical choice because DTLS was not available OpenJDK initially.
>
> Recently, I begin to work about adding coap+tcp and coaps+tcp to Leshan and so I looked again on available security feature in OpenJDK to see if I should rely on it but  I understand there still missing key features for IoT.
>
> My understanding, DTLS 1.2 was added but there is still no support of :
>
> Pre-Shared Key for (D)TLS 1.2 :  PSK is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving. (RFC7925§Section4.2 - TLS / DTLS -Profiles for the Internet of Things)
> Connection Identifier for DTLS 1.2 (RFC 9146) : CID is key feature to limit handshake in dynamic IP environment. (and also be used for load balancing)
> Cipher suite based on AES_128_CCM_8 (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TLS_PSK_WITH_AES_128_CCM_8) which are the recommended or mandatory ciphersuite for CoAP or to create implementation compliant with RFC7925.
>
> If I missed something and one of those feature is already available let me know.
>
> The point I want to raise here it that it's pretty hard for Java IoT developer to support commons Security IoT Feature.
>
> Community can eventually rely on Scandium but it is currently maintain by only 1 person and doesn't follow JSSE API and only target DTLS.
> Other alternative is maybe Bouncy Castle but Pre-shared key seems not available in their JSSE provider.
> There is also possibility to bind native library but this is not so easy and also have drawback.
> All that solution sounds not so good...
>
> So do you think it could make sense to add this kind of feature in OpenJDK ?
> Or Maybe there is already plan to add it ?
>
> (I hope this is the right place for this kind of question)
>
> Thx,
>
> Simon
>