Test 1-3

TEST 1

Test Case ID: BIS-1.2.1 Test Name: TC_OEM_VERIFY_UNIQUE_CRYPTOGRAPHIC_KEYS

Objective

To identify all cryptographic keys and certificates in the device ecosystem and verify them through testing in the presence of the OEM team, ensuring they match the documented list and are functional.

Tools Used

  • OEM-provided key and certificate inventory list

  • OpenSSL or equivalent cryptographic inspection tools

  • Key/certificate management software (e.g., openssl, keytool, certutil)

  • DUT command-line interface or API access for key retrieval

Test Execution Steps

  1. Session Coordination

    • Schedule and conduct the test session with the OEM team present to validate findings jointly.

  2. Key/Certificate Identification

    • Use cryptographic inspection tools and management software to extract and list all keys and certificates used in the DUT and its ecosystem.

  3. Functionality Verification

    • Validate each key and certificate within the DUT’s operational environment to ensure proper functioning (e.g., successful TLS handshake, signature validation).

  4. Cross-Verification with OEM List

    • Compare extracted keys/certificates against the OEM-provided inventory to confirm completeness and detect any discrepancies.

Expected Results for Pass

  • All keys and certificates are identified and match the OEM-provided list.

  • Each key and certificate is functional and used in accordance with its intended purpose.

  • No undocumented or duplicate keys/certificates are present.

Test Observations

(Insert findings here — e.g., "All 7 certificates matched OEM list; TLS server certificate fingerprint verified unique per device; no duplicate keys detected.")

Evidence Provided

  • Screenshots of certificate/key extraction commands and outputs

  • Comparison table between OEM-provided list and extracted list

  • OEM-signed validation sheet

Test Case Result

☐ Pass – All keys/certificates verified and matched OEM documentation ☐ Fail – Discrepancy found between OEM list and actual keys/certificates

Here’s your TEST 2 – BIS-1.2.2 rewritten in a professional, consistent, and audit-ready format to match TEST 1.

TEST 2

Test Case ID: BIS-1.2.2 Test Name: TC_CODE_VERIFY_UNIQUE_CRYPTOGRAPHIC_KEYS

Objective

To perform a structured code review to identify all cryptographic keys and certificates in the device ecosystem and verify their uniqueness, generation method, storage, and usage against secure coding best practices.

Tools Used

  • Source code repository access (Git, SVN, or equivalent)

  • Static Application Security Testing (SAST) tools (e.g., Fortify SCA, SonarQube, Checkmarx)

  • Manual code review checklists for cryptography

  • Secure coding guidelines (e.g., OWASP, NIST SP 800-57)

Test Execution Steps

  1. Codebase Review

    • Perform a structured review of the source code, focusing on the implementation of cryptographic functions and usage of keys/certificates.

  2. Key/Certificate Handling Validation

    • Examine how keys and certificates are generated, stored, and utilized.

    • Ensure keys are generated per device and are not static or reused.

  3. Hard-Coded Key Detection

    • Search for any hard-coded keys or certificates within the code (e.g., .pem, .crt, .key files or inline strings).

  4. Best Practice Compliance

    • Validate that secure coding practices are followed for cryptographic operations, including use of approved algorithms, secure storage, and proper key lifecycle management.

Expected Results for Pass

  • Keys and certificates are dynamically generated per device.

  • No hard-coded or shared keys/certificates are found.

  • Storage and usage of cryptographic material follow secure coding best practices.

  • Code review confirms uniqueness of keys/certificates across devices.

Test Observations

(Insert findings here — e.g., "Code review confirmed RSA 2048-bit per-device keys generated at first boot; no hard-coded certificates detected.")

Evidence Provided

  • Code snippets showing key generation logic

  • SAST tool scan reports

  • Search logs for potential hard-coded secrets

  • OEM confirmation of secure key handling in code

Test Case Result

☐ Pass – Code review confirms per-device unique keys and secure handling ☐ Fail – Hard-coded/shared keys or insecure handling detected

TEST 3

Test Case ID: BIS-1.2.3 Test Name: TC_PROCESS_VERIFY_UNIQUE_CRYPTOGRAPHIC_KEYS

Objective

To verify, through a process audit, the OEM’s key management lifecycle for all cryptographic keys and certificates used in the device ecosystem, ensuring per-device uniqueness and secure handling from generation to destruction.

Tools Used

  • OEM-provided Key Management Lifecycle documentation

  • Key inventory records/logs

  • Audit checklist for cryptographic key handling (aligned with NIST SP 800-57 or equivalent)

  • Access to provisioning and key management systems (read-only)

Execution Steps

  1. Documentation Review

    • Examine OEM-provided key management lifecycle documentation detailing key generation, storage, usage, rotation, and destruction/zeroization.

  2. Lifecycle Tracing

    • Select a sample set of device keys and trace their lifecycle from generation during manufacturing/provisioning to destruction/zeroization at the end of life.

  3. Process Validation

    • Confirm that the generation, storage, and usage of keys follow secure, documented procedures.

    • Verify that no shared keys are used across multiple devices.

  4. Rotation and Renewal Audit

    • Check for documented key rotation and renewal practices.

    • Validate evidence (logs, records) showing these practices are implemented and effective.

Expected Results for Pass

  • Each device has unique cryptographic keys and certificates as per documented processes.

  • Secure handling procedures are followed throughout the lifecycle.

  • Rotation/renewal practices are in place and functioning.

  • No undocumented or insecure key handling practices are detected.

Test Observations

(Insert findings here — e.g., "Audit confirmed per-device RSA key generation at provisioning; rotation performed every 365 days; zeroization confirmed during decommissioning.")

Evidence Provided

  • OEM lifecycle documentation excerpts

  • Key rotation logs

  • Screenshots from key management system

  • Audit checklist results

Test Case Result

☐ Pass – Process audit confirms secure, unique, and compliant key lifecycle ☐ Fail – Discrepancy found between documented process and implementation

Overall Test Result

(Summarize the combined outcome of BIS-1.2.1, BIS-1.2.2, and BIS-1.2.3 — e.g., "All test cases passed; cryptographic keys and certificates confirmed unique per device and securely managed throughout lifecycle.")

Previous1.2 Verify Unique Cryptographic Keys and CertificatesNext1.3 Test On-Chip Debug Interface Security

Last updated

Was this helpful?