![]() |
RFID files:
The list of the desired RFID files can be specified with the rfid/selected_files property. At user's request the GetRfidFile function with PR_RFID_EF_SEL
parameter will read only the files mentioned in this property. In order to read other files the proper file ID defined in the PR_RFID_FILES
enumeration must be specified.
Example:
COM DG1 DG2 DG5 SOD
While there are physical measures possible against skimming these don't address eavesdropping. Therefore, it is understood that States MAY choose to implement a Basic Access Control (BAC) mechanism, i.e. an access control mechanism that requires the consent of the bearer of the MRTD that the data stored in the chip to be read in a secure way. This Basic Access Control (BAC) mechanism prevents skimming as well as eavesdropping.
This access control mechanism is OPTIONAL. If supported, this mechanism MUST ensure that the contents of the chip can only be read after the bearer has willingly offered his MRTD. A chip that is protected by the Basic Access Control (BAC) mechanism denies access to its contents unless the inspection system can prove that it is authorized to access the chip. The inspection system MUST be provided with this information prior to reading the chip. The information has to be retrieved optically/visually from the MRTD (e.g. from the MRZ).
It also MUST be possible for an inspector to enter this information manually on the inspection system in case machine-reading of the MRZ is not possible. Additionally, after the inspection system has been authenticated successfully, it is REQUIRED that the chip enforces encryption of the communication channel between the inspection system and the MRTD's chip by Secure Messaging techniques.
Assuming that the Document Basic Access Keys cannot be obtained from a closed document (since they are derived from the optically read MRZ), it is accepted that the passport was willingly handed over for inspection. Due to the encryption of the channel, eavesdropping on the communication would require a considerable effort.
GX_EACCESS
error, and then the inspection system must read optically the MRZ data printed on the document or give an interface for entering the MRZ data manually. After successfully calling the MakeBAC function, the PR system switches to secure mode and further communications will be encrypted automatically.For this purpose the chip contains its own Active Authentication Key pair (KPrAA and KPuAA). A hash representation of Data Group 15 (Public Key (KPuAA) info) is stored in the Document Security Object (SOD) and therefore authenticated by the issuer's digital signature. The corresponding Private Key (KPrAA) is stored in the chip's secure memory.
By authenticating the visual MRZ (through the hashed MRZ in the Document Security Object (SOD)) in combination with the challenge response, using the MRTD's Active Authentication Key Pair (KPrAA and KPuAA), the inspection system verifies that the Document Security Object (SOD) has been read from the genuine chip, stored in the genuine MRTD.
LoadCertFile
function. The loaded certificates will be used for authenticating the document. The certificate list can be cleared with the ClearCertList
function.
The MakePassiveAuth
is a function returning a boolean value which is set to true if all aspects of the Passive Authentication were checked and none of them failed. For performance reasons the hash checking is made only on the previously read and cached files, so for the full data check, all the files must be read ahead or implicitly checked using the CheckHash
function. For the CheckHash
function to work correctly, the previous call of MakePassiveAuth
function and the pre-reading of the file is necessary.
If no proper country signer or document signer certificate was found for signature authentication the authenticity of the document cannot be determined and the function returns with the GX_EAUTH
error code. The file hashes are loaded and checked before the signature verification, thus the data integrity check is performed even if the authentication fails due to missing certificates.
In the future releases the Passive Authentication handling might be transferred to the prdoc module as it is a document processing job that needs no special chip handling or communication functionalities. In this case the Passive Authentication will be made automatically when the SOD is processed or a new file is read later.
The Active Authentication and Chip Authentication require no external data but only files from the chip. When performing these authentications the needed files are automatically read from the chip. The MakeActiveAuth
and MakeChipAuth
functions return false in case of error.
For Terminal Authentication the certificate chain is built using the CV certificates and private keys loaded previously. If no proper certificate chain can be built then the authentication process fails and the chip does not give access to the sensitive data stored in it. The inspection system can be based on a secure certifiate management system which does generate signatures internally and allocates the actual CV certificates. In this case the MakeTerminalAuth
function can be replaced with the InitTerminalAuth
and the CompleteTerminalAuth
functions and the signature generation can be processed outside the PR SDK.
The standard inspection procedure consists of the following steps:
The advanced inspection procedure consists of the following steps: