Illustration: Samsung Galaxy S25 Ultra TOE Boundary
TOE selected in this report: Samsung Galaxy S25 Ultra (model SM-S938), on stock Samsung firmware with trusted boot and attestation path intact [[SAMSUNGS25US]] [[ANDROIDATTEST]].
This report asks one practical question: how far can one concrete smartphone TOE (Samsung Galaxy S25 Ultra, model SM-S938) be mapped to Common Criteria and SSCD PP requirements for local signing?
Core point: strong signature-control requirements can be enforced on the user device and do not inherently require delegating signing control to a remote trust-service path or a specialized local gadget.
This document does not claim qualification. It shows what is covered, what is still uncovered, and what evidence is still required for ST/SAR evaluation and the formal eIDAS path.
Scope: Full local-QSCD readiness mapping for one concrete device TOE (Samsung Galaxy S25 Ultra, model SM-S938), aligned to the complete applicable SSCD PP Part 2/Part 5 clause set, required assignments/refinements, and evidence expectations for ST/SAR evaluation in the formal eIDAS path [[PPSSCD2]] [[PPSSCD5]] [[PPAPPNOTE]] [[CCPART3]] [[CEMR5]] [[EIDAS910]] [[EIDAS2016650]].
Coverage Target:
Inclusion Rule:
A mapping item is included only when it can be tied to a formal requirement source and mapped to a concrete phone-side control or a clearly stated evidence gap.
Assessment Focus:
Method:
Section 5 uses one format for each mapped item: CRITERIA (formal clause), COVERED (what current S25 controls handle), and UNCOVERED (what still needs closure evidence).
The goal is practical: show what is already defensible with current public evidence, what is technically plausible but not yet evidenced, and what remains required for formal evaluation and certification path work across the full applicable local-QSCD claim scope [[PPSSCD2]] [[PPSSCD5]] [[CCPART3]] [[CEMR5]].
Definitions for the terms and abbreviations used in this report. Formal source pointers are given at clause level where possible: eIDAS Article 25, Article 26, Annex II, SSCD PP Part 2, Section 10.2.2 through 10.2.6, SSCD PP Part 5, Section 9.1.1 through 9.1.4, CC Part 3 assurance classes, and CEM evaluator activities.
This report anchors its legal control model to eIDAS Annex II. Signature-creation data must stay confidential, practically unique, resistant to derivation and forgery, and usable only under signatory control. The data to be signed must also be shown before release so signing cannot occur with silent alteration [[EIDAS910]].
The technical baseline is SSCD PP Part 2 and Part 5, plus the QSCD application note, under the eIDAS standards-pointer path in Decision 2016/650. The evaluation method follows Common Criteria Part 1-3 and CEM [[PPSSCD2]] [[PPSSCD5]] [[PPAPPNOTE]] [[EIDAS2016650]] [[CCPART1]] [[CCPART2]] [[CCPART3]] [[CEMR5]].
ETSI standards are the service-layer comparison set: EN 319 401 for trusted systems, EN 319 411-1/-2 for certificate policy and qualified context, EN 319 412-5 for QCStatements, and TS 119 432 for the remote-signing protocol model [[ETSIEN319401]] [[ETSIEN3194111]] [[ETSIEN3194112]] [[ETSIEN3194125]] [[ETSI119432]] [[ETSI1194311]].
Phone-side evidence (Knox Vault, Android Keystore/KeyMint behavior, and Android attestation) supports three device claims: protected key boundary, controlled key lifecycle, and sign-release gating [[KNOXVAULT]] [[ANDROIDKEYSTORE]] [[ANDROIDATTEST]].
What remains is service-level closure evidence: audited CA/QTSP policy controls, qualified-certificate process evidence, and protocol/interoperability test results. TS 119 432 defines protocol structure, but not the full signer-intent assurance stack [[ETSI119432]].
TOE selected in this report: Samsung Galaxy S25 Ultra (model SM-S938), on stock Samsung firmware with trusted boot and attestation path intact [[SAMSUNGS25US]] [[ANDROIDATTEST]].
This section maps Common Criteria and SSCD protection-profile families to concrete Samsung Galaxy S25 Ultra control points.
Format per criterion: CRITERIA (formal clause and source), COVERED (what S25 currently handles), and UNCOVERED (what still requires closure for conformity).
How to read this section: each card represents one requirement line from the SSCD PP set.
COVERED shows what can already be mapped to S25 controls. UNCOVERED shows what still needs implementation or evaluation evidence.
Families: Cryptographic Support (FCS), User Data Protection (FDP), Identification and Authentication (FIA), Security Management (FMT), Protection of TSF (FPT), Trusted Channel/Path (FTP), Assurance Families (SAR), Cross-Family Closure Items
Focus: key generation, key destruction, and signing operations inside the trusted key boundary.
CRITERIA: Part 2 §10.2.2.1 FCS_CKM.1 - The TOE must generate SCD/SVD using specified algorithms and parameter sizes. [[PPSSCD2]]
COVERED: On S25, key generation is mapped to a hardware-backed Knox Vault StrongBox/KeyMint path, and key-use authorizations are set at key creation/import and enforced by secure key services (for example, purpose, mode, padding, digest, and algorithm/key-size support constraints) [[KNOXVAULT]] [[ANDROIDKEYSTORE]].
UNCOVERED: The ST still must define the exact approved profile (allowed algorithms, key sizes, and related assignments for this TOE claim), and evaluation evidence must show non-approved combinations are rejected [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.2.2 FCS_CKM.4 - The TOE must destroy key material according to a specified method. [[PPSSCD2]]
COVERED: On S25, key lifecycle control is mapped to hardware-backed Knox Vault StrongBox/KeyMint services where key deletion/invalidation removes key handles and prevents further key use through the secure keystore path [[KNOXVAULT]] [[ANDROIDKEYSTORE]].
UNCOVERED: The ST still must define the exact destruction claim (for example logical invalidation versus specific physical erasure semantics) and provide evaluation evidence that deleted key material is not recoverable, including residual-data verification tests [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.2.3 FCS_COP.1 - The TOE must perform the cryptographic signature operation with specified algorithms and parameters. [[PPSSCD2]]
COVERED: On S25, signing operations are mapped to hardware-backed keystore/KeyMint services, where private keys remain non-exportable and signing is invoked via secure key operations rather than raw key extraction [[KNOXVAULT]] [[ANDROIDKEYSTORE]].
UNCOVERED: The ST still must define the exact allowed signing profile (algorithm, key size/curve, digest, padding/mode) and provide evaluation evidence that non-approved signing configurations are rejected [[PPSSCD2]] [[CEMR5]].
Focus: access control and integrity rules for key material, signing operations, and DTBS handling.
CRITERIA: Part 2 §10.2.3.1 FDP_ACC.1/SCD/SVD_Generation - Access control for key generation objects. [[PPSSCD2]]
COVERED: key generation is policy-gated in Knox Vault/KeyMint keystore with trusted boot state checks [[KNOXVAULT]] [[ANDROIDKEYSTORE]] [[ANDROIDATTEST]].
UNCOVERED: The ST and evaluation package still must publish the subject/object role-policy matrix used for generation access decisions [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.3.2 FDP_ACF.1/SCD/SVD_Generation - Attribute-based generation rules. [[PPSSCD2]]
COVERED: enforce key attributes and usage constraints in hardware-backed keystore policy objects [[ANDROIDKEYSTORE]] [[ANDROIDATTEST]].
UNCOVERED: Public sources do not provide negative-authorization test results for attribute-rule enforcement; evaluator evidence still must show unauthorized combinations are rejected [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.3.3 FDP_ACC.1/SVD_Transfer - Access control for SVD transfer. [[PPSSCD2]]
COVERED: allow only public-key/certificate export via approved API endpoint; private key remains non-exportable in hardware [[ANDROIDKEYSTORE]] [[KNOXVAULT]].
UNCOVERED: The ST still must define and test the exact conditions under which SVD export is allowed (for example enrollment/certification state bindings) [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.3.4 FDP_ACF.1/SVD_Transfer - Rules for SVD transfer decisions. [[PPSSCD2]]
COVERED: perform release checks on trusted boot state, key purpose, and authenticated app flow before SVD transfer [[ANDROIDKEYSTORE]] [[ANDROIDATTEST]].
UNCOVERED: Explicit deny rules for untrusted channels still must be stated in the ST and backed by test evidence [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.3.5 FDP_ACC.1/Signature-creation - Access control on sign operation. [[PPSSCD2]]
COVERED: signing only in authenticated session, with key access controlled by Knox Vault/KeyMint path [[KNOXVAULT]] [[ANDROIDKEYSTORE]].
UNCOVERED: The ST still must define per-signature authorization semantics and show event-level enforcement in tests [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.3.6 FDP_ACF.1/Signature-creation - Attribute rules for sign operation. [[PPSSCD2]]
COVERED: enforce key purpose, auth freshness, and boot integrity state before sign execution [[ANDROIDKEYSTORE]] [[ANDROIDATTEST]].
UNCOVERED: Public documentation does not provide conformance evidence that background/invisible signing requests are denied by default; this still requires ST + evaluator tests [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.3.7 FDP_RIP.1 - Residual information protection. [[PPSSCD2]]
COVERED: partially mapped through hardware-backed keystore isolation; explicit buffer-wipe evidence still needs ST test artifacts.
UNCOVERED: Memory-clearing behavior still requires explicit evaluator test artifacts for residual-data handling [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.3.8 FDP_SDI.2/Persistent - Persistent data integrity monitoring and action. [[PPSSCD2]]
COVERED: trusted boot and keystore integrity checks gate key usage and storage operations [[ANDROIDATTEST]] [[ANDROIDKEYSTORE]].
UNCOVERED: If anti-rollback protection is claimed for persistent security data, the ST still must define the mechanism and provide verification evidence [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.3.9 FDP_SDI.2/DTBS - DTBS integrity monitoring and action. [[PPSSCD2]]
COVERED: implement DTBS hash-binding in SCA and pass only canonicalized payloads to keystore sign API.
UNCOVERED: Canonical DTBS/R serialization and mismatch-handling rules still must be fixed in the ST and validated in tests [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 5 §9.1.2 FDP_UIT.1/DTBS - Integrity for DTBS data exchange path. [[PPSSCD5]]
COVERED: authenticated and integrity-protected SCA-to-TOE channel, with key attestation and signed request envelope where needed [[ANDROIDATTEST]] [[ANDROIDKEYSTORE]].
UNCOVERED: Where channel internals are opaque, envelope-level integrity protection and endpoint verification rules still must be fixed and tested in the evaluation package [[PPSSCD5]] [[CEMR5]].
Focus: when user identity and authentication are required before key use and signature release.
CRITERIA: Part 2 §10.2.4.1 FIA_UID.1 - User identification timing. [[PPSSCD2]]
COVERED: before protected key use, the signing ceremony can carry identity-relevant context from app/session state and device attestation signals [[ANDROIDKEYSTORE]] [[ANDROIDATTEST]].
UNCOVERED: the ST still must define how identity context is bound to each signing transaction and provide evaluator evidence that mismatched context is rejected [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.4.2 FIA_UAU.1 - User authentication timing. [[PPSSCD2]]
COVERED: biometric/PIN gating before sign release can be mapped to a hardware-backed key-auth path using Knox Vault and Android keystore authorization controls [[KNOXVAULT]] [[ANDROIDKEYSTORE]].
UNCOVERED: for higher-risk signature classes, step-up authentication triggers and test results still must be defined in the evaluation package [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.4.3 FIA_AFL.1 - Authentication failure handling. [[PPSSCD2]]
COVERED: retry counters and authentication-freshness controls are available through platform authentication and Android keystore authorization policy [[ANDROIDKEYSTORE]] [[ANDROIDATTEST]].
UNCOVERED: lockout thresholds, reset rules, and failure responses still must be specified as TSF-managed data and verified by evaluator tests [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 5 §9.1.1 FIA_UAU.1 refinement - Authentication flow adapted for trusted channel/VAD path. [[PPSSCD5]]
COVERED: trusted-path authentication for VAD entry can be mapped to the system-auth flow and hardware-backed key authorization path [[ANDROIDKEYSTORE]] [[ANDROIDATTEST]].
UNCOVERED: the ST still must define trusted-path guarantees (channel binding, user-visible integrity properties, and failure handling) and provide test evidence for those guarantees [[PPSSCD5]] [[CEMR5]].
Focus: role separation, management functions, and policy control of security-relevant settings.
CRITERIA: Part 2 §10.2.5.1 FMT_SMR.1 - Maintain security roles. [[PPSSCD2]]
COVERED: the S25 stack provides managed policy and protected key-use controls that can host role separation at deployment/app policy level [[ANDROIDKEYSTORE]] [[KNOXVAULT]].
UNCOVERED: the ST still must define explicit Admin vs Signatory role boundaries, and evaluator tests must show unauthorized role actions are rejected [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.5.2 FMT_SMF.1 - List TOE management functions. [[PPSSCD2]]
COVERED: key lifecycle and key-use authorization functions are available through Android keystore/KeyMint controls and hardware-backed enforcement paths [[ANDROIDKEYSTORE]] [[KNOXVAULT]].
UNCOVERED: the ST still must enumerate the exact management-function set and complete required assignments from the PP application note set [[PPSSCD2]] [[PPAPPNOTE]] [[CEMR5]].
CRITERIA: Part 2 §10.2.5.3 FMT_MOF.1 - Restrict security function behavior management. [[PPSSCD2]]
COVERED: sign-enable behavior can be gated through managed policy and app/service authorization layers, with key-use enforcement in hardware-backed keystore controls [[ANDROIDKEYSTORE]] [[KNOXVAULT]].
UNCOVERED: the ST still must define authorized subjects/operations and denial behavior, and evaluation evidence should include tamper-evident logs for enable/disable events [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.5.4 FMT_MSA.1/Admin - Admin management of security attributes. [[PPSSCD2]]
COVERED: admin-side certificate and keystore policy controls are mapped to managed policy and keystore controls [[KNOXVAULT]] [[ANDROIDKEYSTORE]].
UNCOVERED: authenticated admin-channel rules, approval workflow, and role-bound change control still must be specified in the ST and verified in evaluator tests [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.5.5 FMT_MSA.1/Signatory - Signatory management of security attributes. [[PPSSCD2]]
COVERED: signatory-facing controls can be implemented at app/service level while key-use constraints remain enforced in keystore policy objects [[ANDROIDKEYSTORE]] [[KNOXVAULT]].
UNCOVERED: the ST still must define exactly which attributes a signatory may modify and provide user-visible policy transparency with evaluator test evidence [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.5.6 FMT_MSA.2 - Accept only secure attribute values. [[PPSSCD2]]
COVERED: Android keystore authorization parameters support constrained key-use policy values (for example purpose, digest, padding, and authentication requirements) [[ANDROIDKEYSTORE]].
UNCOVERED: the ST still must define the secure-value set for this TOE claim and provide tests showing weak/default-disallowed values are rejected [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.5.7 FMT_MSA.3 - Static attribute initialization. [[PPSSCD2]]
COVERED: key initialization can be mapped to secure defaults such as hardware backing, non-exportability, and authentication-gated use through keystore policy controls [[ANDROIDKEYSTORE]] [[KNOXVAULT]].
UNCOVERED: the ST still must define required default attributes and provide evaluator evidence that insecure defaults cannot be introduced through management flows [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.5.8 FMT_MSA.4 - Attribute value inheritance rules. [[PPSSCD2]]
COVERED: policy layering can be used so derived contexts do not relax parent key-use constraints enforced by keystore authorization policy [[ANDROIDKEYSTORE]].
UNCOVERED: deterministic inheritance rules still must be specified in the ST, with evaluator tests showing no privilege weakening across context transitions [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.5.9 FMT_MTD.1/Admin - Admin TSF data management. [[PPSSCD2]]
COVERED: admin TSF updates can be routed through authenticated managed channels, with key-use policy enforcement anchored in hardware-backed keystore controls [[ANDROIDKEYSTORE]] [[KNOXVAULT]].
UNCOVERED: the ST still must define dual-control semantics for critical admin changes and provide test evidence for approval enforcement and rollback behavior [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.5.10 FMT_MTD.1/Signatory - Signatory TSF data management. [[PPSSCD2]]
COVERED: signatory profile metadata can be managed at app/service layer while protected key material remains isolated in the hardware-backed keystore boundary [[ANDROIDKEYSTORE]] [[KNOXVAULT]].
UNCOVERED: signed change records and tamper-evident audit history for signatory-managed TSF data still must be defined and verified in the evaluation package [[PPSSCD2]] [[CEMR5]].
Focus: protection of security functions against tamper, failure, and integrity compromise.
CRITERIA: Part 2 §10.2.6.1 FPT_EMSEC.1 (Part 5 names FPT_EMS.1) - Emanation resistance. [[PPSSCD2]], Part 5 naming note [[PPSSCD5]]
COVERED: map to Knox Vault components described as resistant to side-channel and fault attacks; PP0084 provides a public evaluation-profile anchor for related secure-component class claims [[KNOXVAULT]] [[BSIPP0084]].
UNCOVERED: the ST and evaluator package still must bind emanation claims to the exact TOE boundary, test method, and measured results; if full-phone evidence is weak, narrow scope to the evaluated secure component boundary [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.6.2 FPT_FLS.1 - Fail secure on failure. [[PPSSCD2]]
COVERED: trusted boot and attestation signals gate keystore operation; when integrity checks fail, protected key use is refused [[ANDROIDATTEST]] [[ANDROIDKEYSTORE]].
UNCOVERED: secure-failure state transitions and recovery behavior still must be defined in the ST and verified with evaluator tests [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.6.3 FPT_PHP.1 - Passive detection of physical attack. [[PPSSCD2]]
COVERED: Knox Vault documentation describes tamper detection hardware monitor and secure integrity-dependent behavior [[KNOXVAULT]].
UNCOVERED: measurable tamper-state outputs, trigger conditions, and response actions still must be specified and backed by evaluator evidence [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.6.4 FPT_PHP.3 - Resistance to physical attack scenarios. [[PPSSCD2]]
COVERED: Knox Vault subsystem is described as tamper-proof and resistant to probing, side-channel, and fault injection attack classes [[KNOXVAULT]].
UNCOVERED: the ST still must define the selected hardware SKU, claimed resistance scope, and evaluator test evidence for the attack classes in scope [[PPSSCD2]] [[CEMR5]].
CRITERIA: Part 2 §10.2.6.5 FPT_TST.1 - Self-test and integrity test functions. [[PPSSCD2]]
COVERED: trusted boot and integrity signaling provide startup validation hooks for security functions [[ANDROIDATTEST]] [[ANDROIDKEYSTORE]].
UNCOVERED: startup/runtime self-test coverage, fault handling, and integrity-test verdict behavior still must be documented and verified in the evaluator package [[PPSSCD2]] [[CEMR5]].
Focus: trusted communication paths for authentication data and data-to-be-signed.
CRITERIA: Part 5 §9.1.3 FTP_ITC.1/VAD - Trusted channel for VAD/auth path. [[PPSSCD5]]
COVERED: the system authentication path can be mapped to hardware-backed key-release gating via Android keystore authorization controls and Knox Vault enforcement boundaries [[ANDROIDKEYSTORE]] [[KNOXVAULT]].
UNCOVERED: secure-attention and anti-overlay guarantees for VAD entry still must be explicitly defined in the ST and verified in evaluator tests [[PPSSCD5]] [[CEMR5]].
CRITERIA: Part 5 §9.1.4 FTP_ITC.1/DTBS - Trusted channel for DTBS path. [[PPSSCD5]]
COVERED: authenticated integrity-protected DTBS channel from SCA to TOE, verified with key attestation and payload binding controls [[ANDROIDATTEST]] [[ANDROIDKEYSTORE]].
UNCOVERED: the ST still must define binding rules between displayed DTBS hash and final sign command, with evaluator evidence that mismatch and substitution cases are rejected [[PPSSCD5]] [[CEMR5]].
Focus: assurance-evidence families required to defend the mapped claim set under Common Criteria evaluation method depth; this assurance workstream applies to the SSCD Part 2 baseline and its Part 5 extension context [[PPSSCD2]] [[PPSSCD5]].
CRITERIA: ADV components in PP Part 2 assurance set: ADV_ARC.1, ADV_FSP.4, ADV_IMP.1, ADV_TDS.3. [[PPSSCD2]]
COVERED: this report defines a candidate TOE boundary and clause-level behavior mapping that can seed architecture and functional-spec evidence structure [[PPSSCD2]] [[CCPART3]].
UNCOVERED: evaluator-grade architecture, subsystem decomposition, complete external-interface specifications, and implementation-representation evidence still must be produced for the selected TOE boundary [[PPSSCD2]] [[CCPART3]] [[CEMR5]].
CRITERIA: AGD components in PP Part 2 assurance set: AGD_OPE.1, AGD_PRE.1. [[PPSSCD2]]
COVERED: operational assumptions and control intent are identified in the mapping narrative and closure tasks [[PPSSCD2]].
UNCOVERED: complete preparative and operational guidance packages (installation, secure configuration, key lifecycle operations, failure handling, and operator responsibilities) still must be authored and test-referenced [[PPSSCD2]] [[CCPART3]] [[CEMR5]].
CRITERIA: ALC components in PP Part 2 assurance set: ALC_CMC.4, ALC_CMS.4, ALC_DEL.1, ALC_DVS.1, ALC_LCD.1, ALC_TAT.1. [[PPSSCD2]]
COVERED: baseline secure-component and platform-security documentation can anchor lifecycle-support scoping for the claimed TOE boundary [[KNOXVAULT]] [[ANDROIDKEYSTORE]].
UNCOVERED: configuration-item inventory, CM system evidence, secure-delivery process, development-security controls, lifecycle model, and toolchain confidence evidence still must be provided as evaluator-verifiable artifacts [[PPSSCD2]] [[CCPART3]] [[CEMR5]].
CRITERIA: ASE components in PP Part 2 assurance set: ASE_CCL.1, ASE_ECD.1, ASE_INT.1, ASE_OBJ.2, ASE_REQ.2, ASE_SPD.1, ASE_TSS.1. [[PPSSCD2]]
COVERED: this report provides an initial structured claim map that can be converted into ST content with traceability from threat/problem statements to requirements and TOE summary specification [[PPSSCD2]] [[CCPART3]].
UNCOVERED: full ST package consistency, dependency closure, and assignment/refinement completion still must be finalized and evaluator-checked for the final claim scope [[PPSSCD2]] [[PPAPPNOTE]] [[CCPART3]] [[CEMR5]].
CRITERIA: ATE components in PP Part 2 assurance set: ATE_COV.2, ATE_DPT.1, ATE_FUN.1, ATE_IND.2. [[PPSSCD2]]
COVERED: section 5 identifies concrete control points and residual claims that can be turned into a structured conformance test plan [[PPSSCD2]].
UNCOVERED: full test design, coverage rationale, developer test evidence, and independent evaluator test results still must be produced across normal, failure, and abuse paths [[PPSSCD2]] [[CCPART3]] [[CEMR5]].
CRITERIA: AVA component in PP Part 2 assurance set: AVA_VAN.5. [[PPSSCD2]]
COVERED: high-risk attack classes and closure tasks are already identified (for example side-channel, fault injection, UI-path manipulation, and trusted-path abuse) as a basis for vulnerability-work planning [[PPSSCD2]] [[CCPART3]].
UNCOVERED: evaluator-grade vulnerability analysis and penetration-test campaign evidence at AVA_VAN.5 depth still must be executed for the final TOE boundary and claim set [[PPSSCD2]] [[CCPART3]] [[CEMR5]].
These are high-impact closure tasks that cut across multiple CC families.
CRITERIA: Trusted display proof for DTBS review before signing
COVERED: partial coverage exists through mapped FDP/FTP controls for integrity-protected DTBS transport and keystore-gated signing flows [[PPSSCD2]] [[PPSSCD5]] [[ANDROIDKEYSTORE]] [[ANDROIDATTEST]].
UNCOVERED: the ST still must define trusted-display/confirmation behavior and cryptographic binding between displayed DTBS hash and final sign command, with evaluator tests for mismatch/substitution rejection [[PPSSCD5]] [[CEMR5]].
CRITERIA: Strong physical/emanation evidence at full-phone scope
COVERED: partial coverage exists through mapped FPT controls and published secure-component claims for Knox Vault, with PP0084 as a public evaluation-profile anchor [[PPSSCD2]] [[KNOXVAULT]] [[BSIPP0084]].
UNCOVERED: full-phone emanation/physical claims still require explicit TOE-boundary definition and measured evaluator evidence; where evidence is weak, narrow scope to the minimal evaluated secure boundary in the ST [[PPSSCD2]] [[CEMR5]].
CRITERIA: Admin/signatory role separation on consumer OS
COVERED: partial coverage exists through mapped FMT policy/management controls and hardware-backed key-use enforcement paths [[PPSSCD2]] [[ANDROIDKEYSTORE]] [[KNOXVAULT]].
UNCOVERED: explicit Admin/Signatory role model, role-restricted management API semantics, and separation-of-duty test evidence still must be defined in the ST [[PPSSCD2]] [[CEMR5]].
CRITERIA: Opaque secure-channel internals in commodity stacks
COVERED: partial coverage exists through mapped FTP trusted-channel requirements and platform attestation/keystore integrity controls [[PPSSCD5]] [[ANDROIDATTEST]] [[ANDROIDKEYSTORE]].
UNCOVERED: explicit signed request/response wrapping, endpoint-binding rules, and attestation-verification behavior still must be specified and verified in evaluation evidence [[PPSSCD5]] [[CEMR5]].
CRITERIA: Insufficient AVA_VAN.5 depth evidence
COVERED: baseline vulnerability-analysis structure is provided by Common Criteria assurance components and CEM methodology [[CCPART3]] [[CEMR5]].
UNCOVERED: a pre-cert penetration plan for S25 still must be executed and evidenced for high-impact vectors (for example TEE escape, UI overlay, side-channel, and fault injection) to support AVA_VAN.5-level claims [[CCPART3]] [[CEMR5]].
Samsung Galaxy S25 Ultra can be profiled toward local-QSCD behavior if the TOE boundary is strict around Knox Vault/keystore components, keys stay hardware-bound, trusted channels are explicit, and ST/SAR evidence is complete [[KNOXVAULT]] [[ANDROIDKEYSTORE]] [[PPSSCD2]] [[PPSSCD5]] [[CCPART3]] [[CEMR5]].
Given that technical baseline, pursuing recognition paths for regular user devices as QSCD-capable local-signing endpoints is worth prioritizing for decentralization and accessibility. This direction is further supported by unresolved remote-signing weaknesses documented in the companion report: https://z-base.github.io/rqscd-report/.