Create rule S7203: Java Keystore files should not disclose cryptographic private keys

rules/S6706/secrets/rule.adoc

@@ -6,31 +6,7 @@ include::../../../shared_content/secrets/rationale.adoc[]
 
 === What is the potential impact?
 
-A cryptographic private key is a piece of sensitive information that is used in
-asymmetric cryptography. They are used in conjunction with public keys to secure
-communications and authenticate digital signatures.
-
-Private keys can be used to achieve two main cryptographic operations,
-encryption or digital signature. Those operations are the basis of multiple
-higher-level security mechanisms such as:
-
-* User authentication
-* Servers authentication, for example in the X509 trust model
-* E-mail encryption
-
-Disclosing a cryptographic private key to an unintended audience can have severe
-security consequences. The exact impact will vary depending on the role of the
-key and the assets it protects.
-
-For example, if the key is used in conjunction with an X509 certificate to
-authenticate a web server as part of TLS communications, attackers will be able
-to impersonate that server. This leads to Man-In-The-Middle-Attacks that would
-affect both the confidentiality and integrity of the communications from clients
-to that server.
-
-If the key was used as part of e-mail protocols, attackers might be able to send
-e-mails on behalf of the key owner or decrypt previously encrypted emails. This
-might lead to sensitive information disclosure and reputation loss.
+include::../../../shared_content/secrets/rationale.adoc[]
 
 == How to fix it
 

rules/S7203/metadata.json

@@ -0,0 +1,2 @@
+{
+}

rules/S7203/secrets/metadata.json

@@ -0,0 +1,61 @@
+{
+  "title": "Java Keystore files should not disclose cryptographic private keys",
+  "type": "VULNERABILITY",
+  "code": {
+    "impacts": {
+      "SECURITY": "BLOCKER"
+    },
+    "attribute": "TRUSTWORTHY"
+  },
+  "status": "ready",
+  "remediation": {
+    "func": "Constant\/Issue",
+    "constantCost": "30min"
+  },
+  "tags": [
+    "cwe",
+    "cert"
+  ],
+  "defaultSeverity": "Blocker",
+  "ruleSpecification": "RSPEC-7203",
+  "sqKey": "S7203",
+  "scope": "All",
+  "securityStandards": {
+    "CWE": [
+      798,
+      259
+    ],
+    "OWASP": [
+      "A3"
+    ],
+    "CERT": [
+      "MSC03-J."
+    ],
+    "OWASP Top 10 2021": [
+      "A7"
+    ],
+    "OWASP Mobile Top 10 2024": [
+      "M1",
+      "M2",
+      "M10"
+    ],
+    "PCI DSS 3.2": [
+      "6.5.10"
+    ],
+    "PCI DSS 4.0": [
+      "6.2.4"
+    ],
+    "ASVS 4.0": [
+      "2.10.4",
+      "3.5.2",
+      "6.4.1"
+    ],
+    "STIG ASD_V5R3": [
+      "V-222642"
+    ]
+  },
+  "defaultQualityProfiles": [
+    "Sonar way"
+  ],
+  "quickfix": "unknown"
+}

rules/S7203/secrets/rule.adoc

@@ -0,0 +1,71 @@
+include::../../../shared_content/secrets/description.adoc[]
+
+== Why is this an issue?
+
+include::../../../shared_content/secrets/rationale.adoc[]
+
+=== What is the potential impact?
+
+include::../../../shared_content/secrets/impact/private_key_disclosure.adoc[]
+
+include::../../../shared_content/secrets/impact/supply_chain_attack.adoc[]
+
+If a third party get access to a keystore containing Android upload key or app signing key, this persone could sign and distribute malicious apps under the same identity as the original app.
+
+== How to fix it
+
+include::../../../shared_content/secrets/fix/revoke.adoc[]
+
+In most cases, if the key is used as part of a larger trust model (X509, PGP,
+etc), it is necessary to issue and publish a revocation certificate. Doing so
+will ensure that all people and assets that rely on this key for security
+operations are aware of its compromise and stop trusting it.
+
+include::../../../shared_content/secrets/fix/recent_use.adoc[]
+
+include::../../../shared_content/secrets/fix/vault.adoc[]
+
+=== Code examples
+
+==== Noncompliant code example
+
+[source,shell,diff-id=1,diff-type=noncompliant]
+----
+keytool -genkey \
+    -keystore release.jks \
+    -alias release \
+    -keyalg RSA \
+    -keysize 2048 \
+    -validity 1000 \
+    -dname "CN=com.example" \
+    -storepass release # Noncompliant, keystore password is easy to guess
+----
+
+==== Compliant solution
+
+[source,shell,diff-id=1,diff-type=compliant]
+----
+echo $STRONG_PWD | keytool -genkey \
+    -keystore release.jks \
+    -alias release \
+    -keyalg RSA \
+    -keysize 2048 \
+    -validity 1000 \
+    -dname "CN=com.example"
+----
+
+//=== How does this work?
+
+//=== Pitfalls
+
+//=== Going the extra mile
+
+== Resources
+
+include::../../../shared_content/secrets/resources/standards.adoc[]
+
+* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m1-improper-credential-usage[Mobile Top 10 2024 Category M1 - Improper Credential Usage]
+* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m2-inadequate-supply-chain-security[Mobile Top 10 2024 Category M2 - Inadequate Supply Chain Security]
+* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m10-insufficient-cryptography[Mobile Top 10 2024 Category M10 - Insufficient Cryptography]
+
+//=== Benchmarks

shared_content/secrets/impact/private_key_disclosure.adoc

@@ -0,0 +1,27 @@
+==== Cryptographic private key disclosure 
+
+A cryptographic private key is a piece of sensitive information that is used in
+asymmetric cryptography. They are used in conjunction with public keys to secure
+communications and authenticate digital signatures.
+
+Private keys can be used to achieve two main cryptographic operations,
+encryption or digital signature. Those operations are the basis of multiple
+higher-level security mechanisms such as:
+
+* User authentication
+* Servers authentication, for example in the X509 trust model
+* E-mail encryption
+
+Disclosing a cryptographic private key to an unintended audience can have severe
+security consequences. The exact impact will vary depending on the role of the
+key and the assets it protects.
+
+For example, if the key is used in conjunction with an X509 certificate to
+authenticate a web server as part of TLS communications, attackers will be able
+to impersonate that server. This leads to Man-In-The-Middle-Attacks that would
+affect both the confidentiality and integrity of the communications from clients
+to that server.
+
+If the key was used as part of e-mail protocols, attackers might be able to send
+e-mails on behalf of the key owner or decrypt previously encrypted emails. This
+might lead to sensitive information disclosure and reputation loss.