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 <cont...@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 <cont...@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 <cont...@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 >
