Test 1-2

Test Case: BIS-2.7a.1

Test Name: TC_TEST_FIRMWARE_DIGITAL_SIGNATURE_PINNING_TLS

---

Objective:

To verify, through documentation, code walkthrough, and controlled simulations, that the device enforces digital signature validation mechanisms during server connections — specifically implementing:

• Strong cipher suites

• Secure TLS versions

• SSL (certificate) pinning

---

Tools Used:

• Source code access (for manual review)

• Wireshark (for TLS handshake analysis)

• Custom server with valid/invalid certificates (for pinning behavior testing)

• Device documentation

---

Test Execution Steps:

1. Documentation Review: Obtain the documentation from the OEM detailing the scenarios where the DUT connects to external servers and the associated security configurations.

2. Security Feature Review: Analyze the declared use of:

   • Secure TLS version (e.g., TLS 1.2 / 1.3)

   • Strong cipher suites (e.g., AES-GCM, ECDHE)

   • Certificate/SSL pinning logic (SHA-256 hash of public key or certificate)

3. Code Walkthrough:

   • Review relevant source code that handles TLS connection initialization.

   • Identify use of certificate pinning libraries or in-house logic.

   • Confirm pinning is hardcoded or dynamically validated against a known public key.

4. Simulated Connection & Analysis:

   • Set up a test server with a valid pinned certificate and observe successful connection.

   • Replace with an untrusted/invalid certificate and confirm the connection is rejected.

   • Use Wireshark to inspect the TLS handshake for cipher suite negotiation and certificate validation.

---

Expected Results for Pass:

• TLS Handshake Analysis: Shows use of strong cipher suites and modern TLS version.

• Code Review: Confirms implementation of SSL pinning (e.g., certificate hash comparison).

• Connection Behavior: DUT connects only when the certificate matches the pinned identity; rejects altered or untrusted certificates.

• No fallback: The DUT does not ignore pinning failures or accept unverified certificates.

---

Test Observations:

(To be filled after live testing with OEM – e.g., details of successful and failed TLS connections, log excerpts, or anomalies.)

---

Evidence Provided:

• Snippets from codebase showing pinning logic

• Wireshark capture files of successful and failed TLS sessions

• Screenshots or logs of connection attempt outcomes

---

Test Case Result:

(Pass / Fail – with brief justification.)

---

Test Case: BIS-2.7a.2

Test Name: TC_TEST_FIRMWARE_DIGITAL_SIGNATURE_PINNING_CERT

---

Objective:

To verify that the device enforces proper certificate validation, including:

• Full certificate chain validation

• Revocation status checks

• Rejection of expired, revoked, or untrusted certificates

---

Tools Used:

• Test server with custom TLS certificates (valid, expired, revoked, untrusted)

• OpenSSL for certificate generation and simulation

• Wireshark (to analyze TLS handshake)

• CRL or OCSP responder (for revocation test)

---

Test Execution Steps:

1. Certificate Validation Process Review:

   • Review the device firmware and configuration to understand how it performs certificate validation.

   • Identify mechanisms in place for:

     • Validating the full certificate chain (leaf to root)

     • Checking certificate expiration

     • Performing revocation checks (OCSP or CRL)

2. Simulated Connection Tests: Establish TLS connections from the DUT to servers with:

   • ✅ A valid and trusted certificate

   • ❌ An expired certificate

   • ❌ A revoked certificate

   • ❌ A certificate from an untrusted CA

   • ❌ A certificate with an incomplete or broken chain

3. Observation & Analysis:

   • Monitor device behavior and connection results for each test scenario.

   • Use Wireshark or logs to validate if the TLS handshake is completed or rejected.

   • Capture logs or output messages related to certificate validation.

---

Expected Results for Pass:

• The DUT successfully connects only to the server with a valid certificate.

• The DUT rejects connections with:

  • Expired certificates

  • Revoked certificates

  • Certificates issued by untrusted or unknown authorities

  • Broken or incomplete certificate chains

• TLS session uses strong protocols (TLS 1.2/1.3) and ciphers.

• Revocation checking is enforced, not bypassed.

---

Test Observations:

(To be filled post execution – e.g., “DUT failed to validate OCSP status”, or “revoked cert was correctly rejected”)

---

Evidence Provided:

• Wireshark packet captures of all connection attempts

• Server certificate configurations and screenshots

• DUT logs showing acceptance/rejection reasons

---

Test Case Result:

(Pass / Fail – with rationale)

---

Overall Test Result:

(Pass / Fail based on both 2.7a.1 and 2.7a.2 outcomes)