Key Missing Feature for IoT

Wed Mar 20 09:19:07 UTC 2024

> any recommendation or example of this kind of work?

Check out these JEPs, the description section:
https://openjdk.org/jeps/329
https://openjdk.org/jeps/8245551
https://openjdk.org/jeps/8281710

In the PSK case the main question is, how is the user going to
configure the keys?
Cheers,
Daniel

wt., 19 mar 2024 o 16:36 Simon Bernard <contact at simonbernard.eu> napisał(a):
>
> > Well I think AES-CCM is a decent candidate to start.
> OK, I will probably take time to see if this is something within my reach.
> (I have limited time by week to give on that and not an expert on this
> topic, so this will be mid/long term task)
>
> > 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'm not sure a mail is a right way to do that, any recommendation or
> example of this kind of work ?
> Eventually I can write some code/documentation in a personal github
> repository.
>
> Regards,
> Simon
>
> Le 18/03/2024 à 09:59, Daniel Jeliński a écrit :
> > 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
> >>