-
Notifications
You must be signed in to change notification settings - Fork 712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to decrypt certain emails in Outlook that can be decrypted with CardOS minidriver #2925
Comments
If needed, I could provide you with an CardOS 5.3 card |
I assume this is some log from the minidriver (?). I am not familiar with that format much. I see Do you have debug logs from the OpenSC when it failed to decrypt the mails. I think this would be helpful. |
The mini driver debug logs are generated by OpenSC: Line 1132 in e420e44
Please find in this gist the full logs. I only removed the pin value: https://gist.github.com/RufusJWB/908b30f39af41964d0863063bbc665be |
I see 4 attempts to decrypt the same block of data using the same APDU, all successful on the opens layer, returning 17 bytes of data. I do not see any failure in the logs. Can the outlook provide some disgnostic information about the failure? One way to check what the atos driver is doing is to record the APDUs it does on the pcsc layer and compare it with the APDU from the above log, but I am not sure how to do that on Windows. It can show some hack/fallback their driver does with some corner-case issue. But its always hard to figure out without specification. |
You may want to use this tool with the Atos driver: https://www.mysmartlogon.com/knowledge-base/trace-apdu-on-windows/ |
This tool didn't work for me under Windows 11 but I was able to find out the necessary registry keys so that AtoS mini driver is creating the logs: Minidriver logging triggered by Outlook process |
Looking at the low leve decryption APDU logs, the logs look almost the same (the important parts inputs and outputs are completely same) for both atos driver and opensc. This is from OpenSC from #2925 (comment):
Which has the same as data from scard logging from #2925 (comment) (I think even with the same values)
We are skipping the external authentication with the card (2-key DES3 is a joke anyway), but we are getting the same decipher so from these logs it is not clear to me what the outlook does not like on the decipher answer from OpenSC that it is getting from the official driver. Next step would be probably looking into the outlook errors/log if they have some better description why and how it failed to decrypt the particular emails with opensc. The thing is that it looks like the mails themselves are not encrypted with the keys on the card, but the key decrypts just some another key that is used to encrypt the mail itself inside of outlook. And given that this operation is happening outside of the opensc/minidriver/atos driver, it might be that the mail was encrypted with some expired key that the atos driver is somehow caching and providing off-band. I think it would help to identify whats different in these emails from the ones that work well. |
RSA raw decryption should return 256 bytes. There is a 1 in 256 chance the first byte may be 0x00. The above logs look like they return 255 bytes and the 2 status bytes. If the modulus for this key has a few leading zero bit too, which limits the size of the input data to the modulus and thus the size of the decrypted data to, change the probability of leading zero bits . What is modules for this key? |
Actually the above comment appears to have been fixed in db41cd9 in 0.21.0. It would still be helpful to know the modulus for this key. |
Indeed, the modulus of the public key starts with two leading zeros:
|
The SPKI looks OK. A Subject Public key info has asn1 as: https://www.rfc-editor.org/rfc/rfc5912 Search for: "layman's guide to asn.1" 1993 from a number of different sites: So the leading 00 says no unused bits. The number of bytes the BIT STRING is (15 * 17) + 2 = 257 one of which is the leading zero. |
Here is one other possible issue. The Altos driver maybe creating container numbers that are different from the container numbers created by OpenSC for the same card. So you may have to Windows like to cache certificates based on these number. So if you switch drivers back and forth windows may get confused. Can you run certutil -v -scinfo using the OpenSC driver? |
Of course: |
I'm now able to reproduce this behavior without MS Outlook. This little c# program can decrypt the CMS content of the problematic email if CardOS is installed
but throws this exception if OpenSC is installed.
|
Running simple diff on the logs, I see the following error in the OpenSC log:
Which is missing on in case the CardOS driver, where it says:
For all certificate keys Similar for the another test:
where OpenSC fails:
And CardOS driver works
Last test is failing for both cases, but it is unrelated as it is a "Windows Hello for Business 1" "reader". I think we checked already that the communication with the card matches and the decipher looks like returning the same deciphered data from the minidriver. The key containers are named differently so I am afraid there might be some caching involved in the windows side, which might be messing up the results (for example if the tool will try to verify cached certificate with non-matching key on the card). Do you have a chance to either try on fresh windows installation without the atos driver or check if the cache can be somehow cleaned up? |
You can delete certificates for the cert store using certutil, MMC's certificate snap-in or Control Panel->Internet Options->Content->Certificates. The user certificates are under Personal and can be removed. The Container ID's for certificate (stored in the cache) is used to find the card with the private key. But if stored by one driver the other driver can not find the matching key on the card. |
I deleted the certificates using the MMC snap-in, but the problem is still there. Next step for me is trying to replicate this on a different machine. I'll try to find a computer with a Windows directly off the shelf. This might take some days... |
fyi: I identified a bug / strange behavior in the dotnet framework, that was hiding the true error message. I described it here: dotnet/runtime#94769 At the end, I was able to locate the problematic call inside of this method:
This call fails |
I've been able to reproduce this issue on a fresh-off-the-shelf Win11 computer. Do you need any additional log files? |
What is the true error message? Run with OpenSC minidriver and get the OpenSC MD log. Also try: Also look at opensc.conf https://github.com/OpenSC/OpenSC/blob/master/etc/opensc.conf.example.in for md_guid_* variables. |
https://gist.github.com/RufusJWB/b1b2183421eb9df81686237262f65f68
https://gist.github.com/RufusJWB/b3fa26d5ba02ea7cc6fd6e649ff23bc8
https://gist.github.com/RufusJWB/9f407007af026f148b3b654899589ef3 |
Here is problem:
In https://gist.github.com/RufusJWB/b1b2183421eb9df81686237262f65f68 running 0.23.0 on Windows 11: lines starting at 8210:
257 bytes -2 bytes status = 255 data bytes. This should be PKCS1.5 padded that should start with 00 02 When called from minidriver card-cardos.c:cardos_decipher should catch this and add leading 0x00 back in but did not.
The next 3 are from minidriver:
Looks like padding sc_pkcs1_strip_02_padding does not handle missing leading zero, so ends up returning 17 bytes EA 18 22 C6 8C 24 DD 45 6C E3 25 25 18 27 43 00 but should have returned 16 bytes with out the trailing 00
Simplest solution is:
|
Thank you so much for your analysis. If you could apply this patch and compile a new release candidate, I'd be happy to test it. |
@RufusJWB PR #2939 should fix the problem. But it needs to be tested by you. Windows install files are built with this PR based on master and can be found by going to #2939 Near the bottom look for "Some checks haven’t completed yet" or "All checks have passed" Based on last built these would be: |
I can confirm it works. Thank you very much for your support and your patience! |
I need to re-open this ticket @frankmorgner . I just installed the latest release version and the problem appears again :-( |
I suggest you open a new ticket with updated logs and a summary of the problems that are still persisting |
Problem Description
I'm evaluating OpenSC as an alternative to AtoS CardOS minidriver in combination with CardOS 5.3 cards. For most of the tasks it works very well, but I have some emails (not all!!) which I can't decrypt in Outlook with OpenSC as minidriver but I can decrypt the same emails with Outlook if the CardOS minidriver by AtoS are active.
I had this problem with 0.23 version and can reproduce it with 0.24-RC1
Proposed Resolution
Steps to reproduce
Switch between CardOS and OpenSC.
Logs
Here you find a log of a failed attempt to decrypt an email.
https://gist.github.com/RufusJWB/ca3ae20cc5616ce92b49436da78631e8
The text was updated successfully, but these errors were encountered: