Open eCard

I have attached the correct screenshot.

Here is a just created fresh log file using the stage branch.

The error is caused by invalid messages sent by the eID Server as described here (page is written in german).
The settings dialog of the Open eCard App provides an option "Ignore Namespaces" in the settings dialog to accept the schema violation. This bug in the Governikus server is known for more than a year now.
Due to the compliance with the eCard specifications it was decided that the Open eCard App per default rejects such invalid messages.

I created a patch which improves the error message slightly, however the real cause can not be displayed so easily. The PAOS part only evaluates the responses from the server, not the messages sent to it. According to this a failure to evaluate the EAC2Input message does not terminate the process. After receiving an EAC2Output message indicating an error, the eID Server should reply with a StartPAOSReponse terminating the procedure which does not happen. Instead the connection is terminated leading to the error reading the XML message.

As I said in my last post, there is an option called "Ignore Namespace" in the settings dialog which disables the XML Schema validation of the incoming messages and returns the elements values even if the namespaces do not match. I highlighted the option in the attached screenshot.

I am using gnome-shell and this dialog does not appear at all. I tried at work and there is an icon in windows system tray which has a right click entry that opens the settings dialog. However, I found no way to open settings on my Debian box. Is there any settings file that I can change this value there or is there any command line flag for that? Any alternative way to set that flag is welcome.

Good news is, I was able to get to the settings dialog using "GNOME on Wayland" option in login screen and switching to OracleJDK using update-java-alternatives tool(I don't know which one made it possible to see the dialog).

Bad news is, nothing has changed. I have attached two screenshots and one log file. I hope we can get further and I am looking forward to applying your workaround and fixes.

Small Update:
I can confirm that legacy.ignore_ns=true is written to the ~/.openecard/openecard.properties.

As the service at https://openid.internet-sicherheit.de/ seems to have multiple (more or less major) deviations from the relevant BSI-specification,
I would recommend to get in contact with the colleagues at https://openid.internet-sicherheit.de/sites/index.jsp?site=Contact.jsp and/or
http://www.governikus.com/de/impressum/5982851.

We are always keen to support the community, but I fear that we are not able to fix all the well known problems in proprietary software components.
Thanks for your understanding. BR, Detlef

Tobias Wich wrote:

Mehdi Sadeghi wrote:

Good news is, I was able to get to the settings dialog using "GNOME on Wayland" option in login screen and switching to OracleJDK using update-java-alternatives tool(I don't know which one made it possible to see the dialog).

It would be good to have a seperate issue opened for that. Was there a relevant error logged when pressing the settings button in the status screen?

I didn't get any errors while using settings. Moreover it seems that settings are stored properly.

Bad news is, nothing has changed. I have attached two screenshots and one log file. I hope we can get further and I am looking forward to applying your workaround and fixes.

Small Update:
I can confirm that legacy.ignore_ns=true is written to the ~/.openecard/openecard.properties.

I seem to have misinterpreted the error message. I pushed a patch to the stage branch which fixes a problem with the certificate chain building. If that does not help, please log more details, especially the PAOS and EAC related info.

I pulled your commit and rebuild the project. I also enabled log for EAC and PAOS in settings. This time I tried to register on skidentity.de (which is listed on openecard website). I got authentication failed error, the log message is attached. Please let me know whether I you have a test site for testing the services.

Today, I tried the latest code for another time. I have attached the error log. I tried setting the level to debug, if still it is not in debug level, please send me the values to put them directly in openecard.properties file (instead of setting them in GUI), working with flat text files is much easire than GUIs right?

Moreover, I changed the status to Bug, since the errors happen with MULTIPLE providers listed on your website and not only with the initial one that I had tried with.

The german eID was designed in a way that it is not possible to differentiate between the transport and activated state. The only option for the citizen is to read the letter he receives and set the PIN prior to using his card.
It would be worth evaluating the PACE response further to see whether this problem can be determined more precisely.

Here is an excerpt from the Card Info file which illustrates what is possible.

The status of the PIN may be determined using the MSE.Set AT
command (cf. [EAC2], Section B.11.1.):

CL ='00'
INS='22' - MSE
P1 ='C1'
P2 ='A4' - PACE
Lc ='0F' - Length of Data field
Data = '800A04007F00070202040202830103'
- 80 0A 04 00 7F 00 07 02 02 04 02 02 - PACE-Protocol-OID
(id-PACE-ECDH-GM-AES-CBC-CMAC-128 (0 4 0 127 0 7 2 2 4 2 2))
- 83 01 03 - PACE Key Reference

The corresponding Response-APDUs indicate the state of the PIN:

(1) 9000 - activated with RC=3
(2) 63C2 - activated with RC=2
(3) 63C1 - suspended with RC=1
(will become resumed after entry of the CAN)
(4) 6283 - deactivated
(will become activated after activation; this state requires new state recognition)
(5) 63C0 - blocked (RC=0)

Note that the PIN may be in a specific transport mode, in which a 5 character secret needs
to be entered and changed to a regular PIN which is 6 characters long. As it is not possible
to recognize that the PIN is in this specific transport mode there is no separate state or
differential identity for this purpose.

Wrong PIN entry is correctly handled by the dialog in recent versions.