Reported on issue 15230 about Portuguese eID. ThinLinc would fail to authenticate with those cards with this in the log: 2014-05-19T15:58:31: Signature operation failed (112) 112 is CKR_MECHANISM_INVALID, meaning that the algorithm we needed for signing isn't available. This is also confirmed by pkcs11-tool: Supported mechanisms: SHA-1, digest SHA256, digest SHA384, digest SHA512, digest MD5, digest RIPEMD160, digest GOSTR3411, digest RSA-PKCS, keySize={512,2048}, hw, decrypt, sign, verify RSA-PKCS-KEY-PAIR-GEN, keySize={512,2048}, generate_key_pair The one we need is SHA1-RSA-PKCS. Comparison with a "good" card: Supported mechanisms: SHA-1, digest SHA256, digest SHA384, digest SHA512, digest MD5, digest RIPEMD160, digest GOSTR3411, digest RSA-X-509, keySize={512,2048}, hw, decrypt, sign, verify RSA-PKCS, keySize={512,2048}, hw, decrypt, sign, verify SHA1-RSA-PKCS, keySize={512,2048}, sign, verify SHA256-RSA-PKCS, keySize={512,2048}, sign, verify MD5-RSA-PKCS, keySize={512,2048}, sign, verify RIPEMD160-RSA-PKCS, keySize={512,2048}, sign, verify RSA-PKCS-KEY-PAIR-GEN, keySize={512,2048}, generate_key_pair After some digging around it turns out that OpenSC is mishandling hash algorithms. The lower layers report what hashes are supported in hardware. This then influences the reported hashes, even though all the hashes in the upper layer are done in software. I.e. looking at those hardware flags is entirely pointless and even damaging.
This fix has been confirmed to solve the issue, and it's been sent upstream: https://github.com/OpenSC/OpenSC/pull/241
Side note: Our cards can't do these hashes in hardware either. But there are several instances of hacky workarounds in the current code. The reason our cards happen to work is because they support RSA-X-509, which entirely unrelated fixes up the hash flags.
r29088.
Tested a bunch of cards using ThinLinc client build 4480, works as expected.
