Skip to content

Interpreting Verification Results ​

The KINEGRAM products report the result of each security mechanism individually (see the eMRTD Result format of the DocVal Service). This document explains how to interpret those results in combination and when a document may be accepted.

The Two Questions a Verification Answers ​

  1. Is the data authentic and unchanged? Answered by Passive Authentication.
  2. Is the chip genuine (not cloned)? Answered by Chip Authentication or Active Authentication.

Passive Authentication alone does not detect cloned chips. A clone carries a bit-perfect copy of the signed data, so Passive Authentication succeeds on it. Clone detection requires Chip Authentication or Active Authentication.

Passive Authentication Covers Only the Data Groups That Were Read ​

passive_authentication is not a statement about the whole chip. It confirms the SOD signature, the certificate chain and the hashes of the Data Groups that were actually read. Data Groups that were not read are not covered.

The Passive Authentication details name them explicitly:

  • data_groups_checked lists the Data Groups that were processed.
  • data_groups_with_valid_hash lists the Data Groups whose hash matched the value in the SOD.

So a session that reads Data Group 1 only can report passive_authentication: true while nothing has been verified about the photo of the face. Before relying on a Data Group, make sure its number appears in data_groups_with_valid_hash.

UNAVAILABLE Is Not FAILED ​

Chip Authentication and Active Authentication are optional mechanisms. A chip supports one, both or neither.

ResultMeaning
SUCCESSThe mechanism was performed and passed.
FAILEDThe mechanism was attempted but did not pass. This is suspicious.
UNAVAILABLEThe chip does not offer this mechanism. Normal for many documents.

Notes:

  • UNAVAILABLE for both Chip and Active Authentication means clone detection is not possible for this document. Whether to accept it is a risk decision for your use case.
  • A SUCCESS result is meaningful only if Passive Authentication also succeeded. Chip and Active Authentication prove that the chip holds the private key belonging to the public key in Data Groups 14/15. Those public keys are trustworthy only after Passive Authentication has verified them. Without valid Passive Authentication a cloned chip could carry its own key pair and still report SUCCESS.

Common Causes for Passive Authentication Failures ​

The Passive Authentication details show which step failed:

ObservationTypical Cause
document_certificate_valid: falseThe Document Signer Certificate is not signed by a trusted Country Certificate, usually because the issuing CSCA certificate is missing from the Master List.
sod_signature_valid: falseThe SOD signature does not verify: the data is corrupt or manipulated.
all_hashes_valid: falseAt least one Data Group was modified after signing.
Fields are nullThe check could not be performed (for example, the SOD could not be parsed). See the error field.

An outdated Master List is the most common cause of Passive Authentication failures for genuine documents. Rule it out first before treating a document as fraudulent.

When May I Accept a Document? ​

Passive Authentication is the precondition for everything below. Unless it succeeds, none of the other results can be trusted, so start there.

  1. Is Passive Authentication true? If not, check the details above. If the Master List is current and the failure persists, do not accept the document. The remaining steps only apply once Passive Authentication has succeeded.
  2. Is any result FAILED? Do not accept the document without manual inspection.
  3. Is Chip Authentication or Active Authentication SUCCESS? The data is authentic and the chip is proven genuine. Accept the document.
  4. Are both UNAVAILABLE? The data is authentic but clone detection was not possible. Accept the document only if your risk profile allows it, or combine the result with additional checks, for example a visual inspection.

Notes:

  • Passive Authentication covers only the Data Groups that were read: confirm that every Data Group you rely on appears in data_groups_with_valid_hash.
  • Also compare the MRZ scanned from the data page with the MRZ read from the chip (Data Group 1), see Understanding the MRZ. A mismatch indicates a manipulated data page.
  • The Date of Expiry of the document is a separate check: the security mechanisms verify authenticity, not whether the document is still valid.
  • All of these checks verify the document. They do not verify that the person presenting it is its holder. Comparing the photo of the face (Data Group 2) with the person is a separate step.