Test 1-3


TEST 1

Test Case ID: BIS-1.5.1 Test Name: TC_OEM_VERIFY_SECURE_STORAGE_OF_SENSITIVE_DATA


Objective

To identify all cryptographic keys, certificates, and sensitive data used in the device ecosystem, verify their storage mechanisms, and confirm secure storage implementation through testing conducted in the presence of the OEM team.


Tools Used

  • OEM-provided documentation of keys, certificates, and sensitive data

  • Hardware Security Module (HSM) or equivalent secure storage inspection tools

  • Secure storage verification utilities (e.g., tpm2_getcap, openssl, keytool)

  • DUT configuration interface (CLI/API) for storage status inspection


Test Execution Steps

  1. Test Plan Preparation

    • Develop a detailed test plan specifying the approach for identifying all keys, certificates, and sensitive data, along with their storage locations and mechanisms.

  2. OEM Coordination

    • Schedule a joint testing session with the OEM team for transparency and validation of findings.

  3. Secure Storage Verification

    • Utilize secure storage inspection tools to validate encryption, integrity protection, and access control for stored keys and sensitive data.

    • Confirm that keys and certificates are stored in secure environments (SE, TPM, TEE) or encrypted with strong cryptography.

  4. Evidence Collection

    • Document the process with screenshots, logs, and photographs demonstrating secure storage in operation.


Expected Results for Pass

  • All keys, certificates, and sensitive data identified and matched with OEM-provided documentation.

  • Verified storage mechanisms align with security requirements (SE, TPM, TEE, or strong encryption).

  • No sensitive data stored in plaintext or insecurely accessible locations.


Test Observations

(Insert findings here — e.g., "Private keys stored in TPM with RSA-2048 encryption; device certificates stored in TEE; no plaintext credentials detected.")


Evidence Provided

  • Annotated OEM documentation excerpts

  • Command outputs showing secure storage verification

  • Screenshots/logs from HSM or TPM inspection

  • OEM-signed validation sheet


Test Case Result

Pass – Secure storage verified as per OEM documentation ☐ Fail – Storage mechanism does not meet security requirements


Here’s your TEST 2 – BIS-1.5.2 rewritten in a professional, consistent, and audit-ready format to match the previous test cases:


TEST 2

Test Case ID: BIS-1.5.2 Test Name: TC_CODE_VERIFY_SECURE_STORAGE_OF_SENSITIVE_DATA


Objective

To identify all cryptographic keys, certificates, and sensitive data used in the device ecosystem, verify their storage mechanisms, and confirm secure storage implementation through structured code review and static analysis.


Tools Used

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

  • Software Composition Analysis (SCA) tools (for dependency security checks)

  • Manual secure coding review checklist (aligned with OWASP and NIST guidelines)

  • OEM-provided source code repository and documentation


Test Execution Steps

  1. Static Code Analysis

    • Run SAST tools in the lab to detect how sensitive data, keys, and certificates are stored and accessed in the codebase.

  2. Manual Secure Storage Review

    • Review critical code segments handling sensitive data to confirm they follow secure storage best practices (e.g., encryption before storage, no plaintext exposure).

  3. Security API Validation

    • Identify and inspect code that interacts with TPM, TEE, or Secure Element.

    • Verify API calls are used securely and according to vendor specifications.

  4. Access Control & Logging Verification

    • Confirm that all sensitive data operations are authenticated, authorized, and logged in compliance with security requirements.


Expected Results for Pass

  • SAST and manual review confirm that sensitive data, keys, and certificates are stored securely using approved mechanisms (TPM, TEE, SE, or strong cryptography).

  • No hard-coded sensitive data or insecure storage locations are detected.

  • All security API calls are correctly implemented with proper authentication and authorization.


Test Observations

(Insert findings here — e.g., "All key storage operations use TPM 2.0 APIs; private keys encrypted with AES-256 before storage; no plaintext sensitive data detected in codebase.")


Evidence Provided

  • SAST tool output reports

  • Code excerpts showing secure storage implementation

  • Audit trail of API calls to secure elements

  • OEM confirmation of secure coding practices


Test Case Result

Pass – Code review confirms secure storage is correctly implemented ☐ Fail – Insecure storage practices or incorrect API usage detected


Here’s your TEST 3 – BIS-1.5.3 rewritten in a professional, consistent, and audit-ready format to match the earlier test cases:


TEST 3

Test Case ID: BIS-1.5.3 Test Name: TC_PROCESS_VERIFY_SECURE_STORAGE_OF_SENSITIVE_DATA


Objective

To verify, through process audit, that all cryptographic keys, certificates, and sensitive data used in the device ecosystem are securely managed throughout their lifecycle in alignment with the vendor’s documented Key Management Life Cycle. This includes verifying secure storage during generation, usage, and destruction/zeroization phases.


Tools Used

  • OEM-provided Key Management Life Cycle documentation

  • Process audit checklist (aligned with NIST SP 800-57 or equivalent)

  • Access to secure key management systems/logs (read-only)

  • Interview records with OEM security/process personnel


Execution Steps

  1. Documentation Analysis

    • Review the vendor’s Key Management Life Cycle documentation, including details of key generation, secure storage, destruction/zeroization, validity periods, and rotation schedules.

  2. Practice Verification

    • Audit actual key management practices within the operational environment to ensure they match the documented processes.

  3. Secure Storage Context Assessment

    • Evaluate secure storage solutions (SE, TPM, TEE, or strong cryptography) as they are applied during the key lifecycle, with emphasis on generation and destruction phases.

  4. Security Control Confirmation

    • Confirm that implemented processes maintain confidentiality and integrity of keys and certificates at all lifecycle stages, and that any rotation or renewal processes are followed.


Expected Results for Pass

  • The key management lifecycle is fully implemented as documented by the vendor.

  • Keys and certificates are securely generated, stored, rotated, and destroyed using approved secure storage mechanisms.

  • No deviations from documented processes are identified during the audit.


Test Observations

(Insert findings here — e.g., "Key rotation occurs annually as documented; zeroization logs confirm secure destruction; TPM used for all private key storage.")


Evidence Provided

  • Audit checklist results

  • Key management system logs/screenshots

  • OEM process flow diagrams for key lifecycle management

  • OEM-signed compliance confirmation


Test Case Result

Pass – Key management lifecycle securely implemented as documented ☐ Fail – Deviations found between documentation and actual practices


Overall Test Result

(Summarize the outcome of BIS-1.5.1, BIS-1.5.2, and BIS-1.5.3 — e.g., "All test cases passed; sensitive data, keys, and certificates confirmed to be securely stored and managed throughout their lifecycle.")


Last updated

Was this helpful?