Mismatch in signature

[nema-oss]

OS: Fedora 42
Browser: Firefox

issue: after inserting the PIN from the pinpad, the site immediately shows "An error occured while handling your request.". Retried multiple times, the output of the console is always:

code: 7
​
message: "The signature could not be computed. Please make sure your hash is 40 character hex string (e.g. 01FFAABD9DE8801F8FF001FFAABD9DE8801F8FF0)"

after the PIN was inserted.

The connective-backend is running, the extension is installed and I double checked everything in the README. I can post the stack of the error as well if that can help. Last time I used the connective-plugin was with Nobara 40 a few months ago and it was working flawlessly. I also tried adding and removing the official eid browser plugin, and nothing changed. The eid .rpm is installed and I can even view my card in the viewer.

[roelderickx]

Hi nema,

The official plugin selects a different signing algorithm. I am not sure it will solve the problem but can you try to modify the 0x08 into 0x01 on line 480 of the backend?

[nema-oss]

it has the same exact behaviour (code 7) with 0x01

[roelderickx]

I had been busy during the weekend, but I'll try to investigate this since asap it is potentially blocking for everyone.

• Which site are you trying to log in?
• Can you provide the request of the failing call?

[nema-oss]

No worries!

I am trying on itsme to update my address. Looking at the network monitor, I don't see any failing request. The only 409 I get has the following response payload:

"The SignIdPlugin setting is not enabled. Check configuration for tenant 4."

and it is directed towards https://bmid-id.connective.eu/configuration/plugin/latestversion/d17e6764c6af4863a258163d410c0221, but it's before the detection of the card reader, so I don't think it's related.

I tried with both the official plugin enabled and disabled, and nothing changes when looking at the network.

[roelderickx]

"The SignIdPlugin setting is not enabled. Check configuration for tenant 4."

and it is directed towards https://bmid-id.connective.eu/configuration/plugin/latestversion/d17e6764c6af4863a258163d410c0221, but it's before the detection of the card reader, so I don't think it's related.

I think that is in fact good news :-)

What I meant with the failing call is the call leading to the infamous 40 characters hash error message. Open the developer console using Ctrl-J and have a look at the console tab while trying to use the id-card. There should be messages starting with IN containing the requests itsme is sending us. Can you provide at least the last message?

[nema-oss]

Sorry, here is the last lines of the output:

stderr output from native app com.connective.signer: IN {"cmd":"COMPUTE_AUTHENTICATION","reader":"Generic USB2.0-CRW [Smart Card Reader Interface] (20070818000000000) 00 00","hash":"","activationToken":"","isRequest":true} stderr output from native app com.connective.signer: Card applet version: 18 stderr output from native app com.connective.signer: Card 0x6C delay required: 50 ms stderr output from native app com.connective.signer: OUT {"pinRemainingAttempts": -1, "pinValid": true, "valid": false}

I removed the values of the hash and of the token, as I don't know if I should be sharing those.

[roelderickx]

Ok thanks, it was the hash I was interested in. Do you remember the length? Did it have leading or trailing zeroes?

[nema-oss]

It is 64 hex chars long, without any leading or trailing zeroes

[roelderickx]

Interesting. I'll have a look if I can replicate this, it may be related to the new id card you are using, in which case it is a general problem. To be continued.

[nema-oss]

Thank you. I just wanted to say that I've always used the same card reader. However, I did see trailing zeros in OUT calls that come before the ones I shared. After READ_FILE, data is composed of 5000 hex chars, of which 2608 are trailing zeros. Then, another READ_FILE is issued and data is composed of 2016 hex chars with 364 trailing zeros. Then, another 2 READ_FILE commands are issued, resulting in a 5000 hex chars data with 2720 trailing zeros and the last one with 2016 chars without any trailing or leading zeros. This then produces the output I shared before. I hope this can help you.

[roelderickx]

Hi nema,

Sorry fo the delay. I tried it a few times, both in a debug session and on the live itsme website and for me it works fine...

• The READ_FILE call has trailing zeroes as well
• The COMPUTE_AUTHENTICATION call works as expected with an input hash with length 64 hex characters

However, since I don't use itsme (they even sent me text messages my account is blocked) I can only test the signup procedure, which brought me at least beyond the authentication call.

Intriguing :-) The question is which component is to blame. Itsme? Or the plugin I wrote? One way to find out is to send the request to the official plugin in Windows in debug mode, but unfortunately it requires some hacking (and a Windows installation).

1. Extract the message from the logs. You need the IN part between curly brackets, eg {"cmd":"COMPUTE_AUTHENTICATION","reader":"Generic USB2.0-CRW [Smart Card Reader Interface] (20070818000000000) 00 00","hash":"","activationToken":"","isRequest":true}
2. Make sure to copy a recent request, the token refreshes every day around 6pm and the official plugin verifies its correctness before doing anything else
3. Save the message to a file, but here is the hard part: the first 4 bytes should be a 32-bit binary value indicating the length of the message. Let's assume you call the file compute_authentication.txt
4. run the official plugin from the command prompt with the following parameters, passing the generated file as input: extension-native.exe com.connective.signer.json {4f643bc8-78f5-49c6-8efd-78ee30289f0b} < compute_authentication.txt
5. Make sure the card reader is connected while running the command, you will need to input your pin code.
6. Verify if the output is the same as the output you captured earlier in the browser log in linux. If they're not, what are the differences? If they are equal the question remains how it is able to work in Windows? Or doesn't it?

For step 3 I can provide a short script to convert the message if you need it.

[wernermaes]

Maybe I can test the request to the official plugin in Windows debug mode.
I may need some script for Step 3 (assuming I can't write it myself)

[roelderickx]

Quick, dirty and untested :-) You have to modify the message in the function call at the end:

#!/usr/bin/env python3

import sys
import struct
import json

def write_message(message, filename):
    with open(filename, 'wb') as f:
        message_bytes = bytes(message, 'utf-8')
        f.write(struct.pack('@I', len(message_bytes)))
        f.write(message_bytes)
        f.flush()

write_message('{"cmd":"COMPUTE_AUTHENTICATION","reader":"Generic USB2.0-CRW [Smart Card Reader Interface] (20070818000000000) 00 00","hash":"","activationToken":"","isRequest":true}', 'compute_authentication.txt')

[wernermaes]

Had some time but it does not work (could be my fault)

I extracted a message from the logs, saved it to a file compute_authentication.txt
Then I ran .\python.exe .\compute.py (with compute.py your quick and dirty script)

Then

Get-Content .\compute_authentication.txt | .\extension-native.exe com.connective.signer.json {4f643bc8-78f5-49c6-8efd-78ee30289f0b}
Q {"error": { "code":99,"id":99,"message":"No request received after 10 seconds"}}

Because

cat .\compute_authentication.txt
¦{"cmd":"COMPUTE_AUTHENTICATION","reader":"Generic USB2.0-CRW [Smart Card Reader Interface] (20070818000000000) 00 00","hash":"","activationToken":"","isRequest":true}

Remark < RedirectionNotSupported in powershell

Well I must be doing something wrong