Extended Access Control Specification

Extended Access Control version 2 (EAC) defined by the Federal Office for Information Security (BSI) [1] in the Technical Guideline TR-03110 [2]. It is designed to be compatible and submitted to be standardized with ICAO Machine Readable Travel Documents Doc 9303 [3]. EAC consists of three subsequent steps:

  1. Password Authenticated Connection Establishment (PACE)
  2. Terminal Authentication (TA)
  3. Chip Authentication (CA)

The following description of PACE, TA and CA is cited from BSI TR-03110 (Version 2.05). With Terminal or PCD and MRTD chip or PICC we denote the two parties involved in EAC.

Password Authenticated Connection Establishment

The PACE Protocol is a password authenticated Diffie-Hellman key agreement protocol that provides secure communication and explicit password-based authentication of the MRTD chip and the terminal (i.e. MRTD chip and terminal share the same password \(\pi\)).

Protocol Specification

The following steps are performed by the terminal and the MRTD chip:

  1. The MRTD chip randomly and uniformly chooses a nonce \(s\), encrypts the nonce to \(z=\operatorname{E} ( K_\pi , s)\), where \(K_\pi=\operatorname{KDF}_\pi(\pi)\) is derived from the shared password \(\pi\), and sends the ciphertext \(z\) together with the static domain parameters \(D_{\text{PICC}}\) to the terminal.

  2. The terminal recovers the plaintext \(s=\operatorname{D}( K_\pi , z )\) with the help of the shared password \(\pi\).

  3. Both the MRTD chip and the terminal perform the following steps:

    1. They compute the ephemeral domain parameters \(\widetilde{D} =\operatorname{Map}( D_{\text{PICC}} , s )\).

    2. They perform an anonymous Diffie-Hellman key agreement based on the ephemeral domain parameters and generate the shared secret.

      \[K =\operatorname{KA} ( \widetilde{SK_{\text{PICC}}} , \widetilde{PK_{\text{PCD}}} , \widetilde{D}) =\operatorname{KA} ( \widetilde{SK_{\text{PCD}}} , \widetilde{PK_{\text{PICC}}} , \widetilde{D} )\]

      During Diffie-Hellman key agreement, each party SHOULD check that the two public keys \(\widetilde{PK_{\text{PICC}}}\) and \(\widetilde{PK_{\text{PCD}}}\) differ.

    3. They derive session keys.

      \[K_{\text{MAC}} =\operatorname{KDF}_{\text{MAC}} ( K )\text{ and } K_{\text{Enc}}=\operatorname{KDF}_{\text{Enc}} ( K )\]
    4. They exchange and verify the authentication token.

      \[T_{\text{PCD}} =\operatorname{\text{MAC}}( K_{\text{MAC}} , \widetilde{PK_{\text{PICC}}} )\text{ and }T_{\text{PICC}} =\operatorname{\text{MAC}}( K_{\text{MAC}} , \widetilde{PK_{\text{PCD}}} )\]

ECDH Mapping

Let \(G\) and \(\widetilde{G}\) be the static and an ephemeral base point on the elliptic curve.

Generic Mapping

The function \(\operatorname{Map}:G \mapsto \widetilde{G}\) is defined as \(\widetilde{G} =s\cdot G+H\), where \(H \in \langle G \rangle\) is chosen s.th. \(\log_G H\) is unknown. The point \(H\) SHALL be calculated by an anonymous Diffie-Hellman Key Agreement.

Note: The key agreement algorithm ECKA prevents small subgroup attacks by using compatible cofactor multiplication.

Integrated Mapping

The Integrated ECDH Mapping is specified by ICAO.

DH Mapping

Let \(g\) and \(\widetilde{g}\) be the static and an ephemeral generator.

Generic Mapping

The function \(\operatorname{Map}: g \mapsto \widetilde{g}\) is defined as \(\widetilde{g} =g^s \cdot h\), where \(h \in \langle g \rangle\) is chosen s.th. \(\log_g h\) is unknown. The group element \(h\) SHALL be calculated by an anonymous Diffie-Hellman Key Agreement.

Note: The public key validation method described in RFC 2631 MUST be used to prevent small subgroup attacks.

Integrated Mapping

The Integrated DH Mapping is specified by ICAO.

Terminal Authentication

The Terminal Authentication Protocol is a two move challenge-response protocol that provides explicit unilateral authentication of the terminal.

In this protocol \(ID_{\text{PICC}}\) is an identifier of the MRTD chip:

  • If BAC is used \(ID_{\text{PICC}}\) is the MRTD chip’s Document Number as contained in the MRZ including the check digit.
  • If PACE is used \(ID_{\text{PICC}}\) is computed using the MRTD chip’s ephemeral PACE public key, i.e. \(ID_{\text{PICC}} =\operatorname{Comp} (\widetilde{PK_{\text{PICC}}})\)

Note: All messages MUST be transmitted with Secure Messaging in Encrypt-then-Authenticate mode using session keys derived from PACE or Chip Authentication.

Protocol Specification

The following steps are performed by the terminal and the MRTD chip.

  1. The terminal sends a certificate chain to the MRTD chip. The chain starts with a certificate verifiable with the CVCA public key stored on the chip and ends with the Terminal Certificate.

  2. The MRTD chip verifies the certificates and extracts the terminal’s public key \(PK_{\text{PCD}}\).

  3. Version 2 only:

    1. The terminal generates an ephemeral Diffie-Hellman key pair \((\widetilde{SK_{\text{PCD}}} , \widetilde{PK_{\text{PCD}}} , D_{\text{PICC}} )\), and sends the compressed ephemeral public key \(\operatorname{Comp}( \widetilde{PK_{\text{PCD}}})\) to the MRTD chip.
    2. The terminal may send auxiliary data \(A_{\text{PCD}}\) to the MRTD chip.
  4. The MRTD chip randomly chooses a challenge \(r_{\text{PICC}}\) and sends it to the terminal.

  5. The terminal responds with the signature.

    \[s_{\text{PCD}} =\operatorname{Sign}( SK_{\text{PCD}} , ID_{\text{PICC}} \parallel r_{\text{PICC}} \parallel \operatorname{Comp}(\widetilde{PK_{\text{PCD}}})\parallel A_{\text{PCD}} )\]
  6. The MRTD chip checks that

    \[\operatorname{Verify} ( PK_{\text{PCD}} , s_{\text{PCD}} , ID_{\text{PICC}}\parallel r_{\text{PICC}}\parallel \operatorname{Comp}(\widetilde{PK_{\text{PCD}}})\parallel A_{\text{PCD}} ) = \operatorname{true}\]

Chip Authentication

The Chip Authentication Protocol is an ephemeral-static Diffie-Hellman key agreement protocol that provides secure communication and unilateral authentication of the MRTD chip.

The protocol provides explicit authentication of the MRTD chip by verifying the authentication token and implicit authentication of the stored data by performing Secure Messaging using the new session keys.

Protocol Specification

In this version Terminal Authentication MUST be performed before Chip Authentication, as the terminal’s ephemeral key pair \((\widetilde{SK_{\text{PCD}}}, \widetilde{PK_{\text{PCD}}}, \widetilde{D_{\text{PICC}}})\) is generated as part of Terminal Authentication.

  1. The MRTD chip sends its static Diffie-Hellman public key \(PK_{\text{PICC}}\) and the domain parameters \(D_{\text{PICC}}\) to the terminal.

  2. The terminal sends the ephemeral public key \(\widetilde{PK_{\text{PCD}}}\) to the MRTD chip.

  3. The MRTD chip computes the terminal’s compressed ephemeral public key \(\operatorname{Comp}(\widetilde{PK_{\text{PCD}}})\) and compares this to the compressed public key received in Terminal Authentication.

  4. Both the MRTD chip and the terminal compute the shared secret.

    \[K=\operatorname{KA}(SK_{\text{PICC}}, \widetilde{PK_{\text{PCD}}}, D_{\text{PICC}})=\operatorname{KA}(\widetilde{SK_{\text{PCD}}}, PK_{\text{PICC}}, D_{\text{PICC}})\]
  5. The MRTD chip randomly chooses a nonce \(r_{\text{PICC}}\), derives session keys \(K_{\text{MAC}}=\operatorname{KDF}_{\text{MAC}}(K, r_{\text{PICC}})\) and \(K_{\text{Enc}} = \operatorname{KDF}_{\text{Enc}} ( K , r_{\text{PICC}} )\) for Secure Messaging from \(K\) and \(r_{\text{PICC}}\), computes the authentication token \(T_{\text{PICC}} =\operatorname{\text{MAC}}( K_{\text{MAC}} , \widetilde{PK_{\text{PCD}}})\) and sends \(r_{\text{PICC}}\) and \(T_{\text{PICC}}\) to the terminal.

  6. The terminal derives session keys \(K_{\text{MAC}} =\operatorname{KDF}_{\text{MAC}} ( K , r_{\text{PICC}})\) and \(K_{\text{Enc}} =\operatorname{KDF}_{\text{Enc}} ( K , r_{\text{PICC}} )\) for Secure Messaging from \(K\) and \(r_{\text{PICC}}\) and verifies the authentication token \(T_{\text{PICC}}\).

To verify the authenticity of the \(PK_{\text{PICC}}\) the terminal SHALL perform Passive Authentication.

[1]https://www.bsi.bund.de
[2]https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/TR03110/BSITR03110.html
[3]http://www.icao.int/Security/mrtd/Pages/Doc9393.aspx