Crypto: Add Java Cryptographic Analysis Queries

[bdrodes]

These are some example queries that check the cryptography present in output from a java source repo. Again, these build on the existing examples both in java and in other CBOM and cryptographic issue checking codeQL queries:

InsecureNonceGeneration.ql - as before
InsecureNonceSource.ql - as before
KnownWeakKDFIterationCount.ql - as before
NonAESGCMCipher.ql - detects non-AES in GCM mode ciphers. Can be updated to be 'non AES256 in GCM mode' but this gives more alerts on inferred key lengths.
ReusedNonce.ql - as before
UnknownKDFIterationCount.ql - as before
WeakAsymmetric.ql - finds weak asymmetric RSA ciphers using key lengths < 2048
WeakBlockModes.ql - similar to NonAESGCM, this finds instances of known-bad block modes ECB, CFB, OFB, and CTR
WeakHashing.ql - finds potentially weak hashing instances using the whitelist of SHA256, SHA384, and SHA512 (though this is yet to be checked against SHA3 variants)
WeakKDFIterationCount.ql - as before
WeakKDFKeySize.ql - as before
WeakRSA.ql - an allternative method from WeakAsymmetric.ql, but functionally the same.
WeakSymmetricCiphers.ql - detects known-weak ciphers from a blocklist of DES, TripleDES, DoubleDES, RC2, RC4, IDEA, and Blowfish.

[bdrodes]

This PR is based on #20568, made a copy to be able to do my own quick edits.

[Copilot]

Pull Request Overview

This PR adds comprehensive Java cryptographic analysis queries to detect various security vulnerabilities and weak cryptographic practices. The changes include 11 new CodeQL analysis queries and updates to the underlying cryptographic models to improve consistency in naming conventions.

• Adds 11 new analysis queries to detect weak cryptographic implementations including weak symmetric/asymmetric ciphers, poor block modes, weak hashing algorithms, and insecure key derivation functions
• Updates cryptographic model naming from "Family" to "Type" for better consistency across elliptic curve and hash algorithm classifications
• Modifies precision levels for some existing queries to improve analysis accuracy

Reviewed Changes

Copilot reviewed 16 out of 16 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
shared/quantum/codeql/quantum/experimental/Standardization.qll	Renames elliptic curve type definitions from "Family" to "Type"
shared/quantum/codeql/quantum/experimental/Model.qll	Updates method names and documentation to use "Type" instead of "Family"
java/ql/src/experimental/quantum/Analysis/*.ql	Adds 11 new analysis queries for detecting cryptographic vulnerabilities
java/ql/lib/experimental/quantum/JCA.qll	Updates method implementations to use new "Type" naming convention
cpp/ql/lib/experimental/quantum/OpenSSL/*.qll	Updates C++ OpenSSL bindings to match new naming conventions

[Copilot]

The variable configSrc is declared in the from clause but never assigned a value in the where clause, which will cause the query to fail or produce no results. Either remove configSrc from the select statement or add a condition to assign it a value.

Suggested change

	not Crypto::isEllipticCurveAlgorithmName(algName)
	not Crypto::isEllipticCurveAlgorithmName(algName) and
	configSrc = op.getConfigSource()

[nicolaswill]

This comment does indeed point out an issue with the query. I would suggest a rewrite to something like the following (I have not tested this change... it's a draft revision):

/**
 * @name Weak Asymmetric Key Size
 * @id java/quantum/weak-asymmetric-key-size
 * @description An asymmetric cipher with a short key size is in use
 * @kind problem
 * @problem.severity error
 * @precision high
 * @tags quantum
 *       experimental
 */

import java
import experimental.quantum.Language

from
  Crypto::KeyOperationAlgorithmNode alg, Crypto::NodeBase configSrc, string configSrcDesc,
  int keySize, string algName
where
  algName = alg.getAlgorithmName() and
  // Can't be an elliptic curve
  not Crypto::isEllipticCurveAlgorithmName(algName) and
  (
    // Case 1: Key size from config source
    exists(Crypto::GenericSourceNode src |
      src = alg.getKeySize() and
      keySize = src.toString().toInt() and
      configSrc = src and
      configSrcDesc = src.toString()
    )
    or
    // Case 2: Fixed key size (no config source, or config source is fine)
    not exists(Crypto::GenericSourceNode src |
      src = alg.getKeySize() and
      src.toString().toInt() < 2048
    ) and
    keySize = alg.getKeySizeFixed() and
    configSrc = alg and
    configSrcDesc = "(implicit)"
  ) and
  keySize < 2048
select alg,
  "Use of weak asymmetric key size (" + keySize.toString() + " bits) for algorithm " + algName +
    " at config source $@.", configSrc, configSrcDesc

[bdrodes]

@nicolaswill this was meant to be a draft PR while I fix up the last issues, sorry about that. I don't see how I can move it back to draft, so I'll leave this open but ping when it is ready for final review.

[nicolaswill]

I'm hesitant to merge this into the out-of-box queries, as many of these are prescriptive about allowed/disallowed algorithms or thresholds for things like iteration count. I would suggest putting these into an Examples directory.

[bdrodes]

@nicolaswill what do you think of an asymmetric key size checker more like this:

from Crypto::KeyArtifactNode key, int keySize
where
  key.getCreatingOperation().getAKeySizeSource().asElement().(Literal).getValue().toInt() = keySize and
  key.getAKnownAlgorithm() != <TODO: COMPARE TYPE HERE to elliptic curve or symmetric alg> and
  keySize < 2048 
select key, "Use of weak asymmetric key size (" + keySize.toString() + " bits) for algorithm "

My thought is we check the creation operations, then separately I could ask for any key op that is asymmetric with a key size that is also statically known to be too small but I think for most cases that defaults to doing basically this no? The benefit here is I don't need an operation to detect a bad key. I just keep having issues comparing types I never seem to be able to do it right.

[nicolaswill]

Is instanceof Expr necessary here?