Hello everyone,

Today I tried initializing a brand new Atos CardOS 5.3 smartcard without success. As I saw that 5.3 is still fresh on the repo, I'm proposing my help.

Specs

Gentoo Linux (Linux 4.9.34-gentoo)
OpenSC version 0.17.0 (custom ebuild, branch master, last commit 3d187d9)
pcsc-lite version 1.8.22 (Enabled features: Linux x86_64-pc-linux-gnu serial usb libudev)
Gemalto IDBridge K30 (Generic CCID USB SmartCard Reader)
Atos CardOS V5.3 (Infineon Solid Flash Chip - SLE78CFX3000P)

Actual behaviour

cardos-tool -f -r 1
currently only CardOS M4.2B, M4.2C, M4.3B and M4.4 are supported, aborting

Expected behaviour

cardos-tool -f -r 1
Good job man, you did it !

Steps to reproduce

1- Plug a uninitialized (Current life cycle: 52 (manufacturing)) CardOS V5.3 chip into a reader
2- Try to cardos-tool -f

Logs

opensc-tool --reader 1 --atr

cardos-tool -vv -i -r 1

Informations

I am at your disposal for testing as well as brute-forcing apdu commands into my chip.

References

#947
#1003
#1079

Edit 1: Forgot my manners :)

After bypassing the version info check (

@Jakuje?

That would be one of the thing I would like to have a look at some point, but currently I don't have any uninitialized CardOS 5 card I could play with nor I have a lot of time to do that. It is hard with these closed-specification cards.
I am able to offer help such as listing what is/should be in successfully initialized card, but probably not much more in close future.

If you want, I can plug the card into a server at home and let you play with it inside a virtual machine. I mean, it's not that I can use it right now so... :)

I edited the title to match what this ticket is about, new code for improved compatibility.

As I was browsing the web for informations, I stumbled upon #768. My problem is somewhat related to this issue.

The problem that the card management of CardOS 5 should be substantially different from the 4.x versions, according to the #283. I recommend reading also that PR, which also discuss some of the issues with 5.x and might give you some hints what is missing. Unfortunately, the code as a whole is not available and therefore ready for re-implementation, which is huge task without any substantial knowledge about the card.

The only thing I'm able to do is to try to initialize the card with the CardOS API Driver on a Windows VM and sniff the USB data to reverse engineer the apdu codes sent to it. But I have one shot, unless I order more chips. The code itself is a whole new problem as I am no developer.

Also, would you be kind to confirm that an initialized 5.3 card works with OpenSC ?

Yes, the initialized CardOS 5.3 cards work with OpenSC, at least to the extend of pkcs11-tool --test using PKCS#11 interface with RSA keys.

I tried to initialise the chip with the CardOS API Windows app but it didn't ask for a custom SO PIN. The card is now in operational status but cannot talk with OpenSC. I dumped the CCID commands with Wireshark and usbmon. If you want the dump file, just ask for it, i'm not sure if I can share it publicly (cause of NDAs and whatnot).

The card is working fine with Windows Crypto API but is unreadable by pcks15-tool on Linux. Also, pkcs11-tool --test is segfaulting.

@Jakuje @NainKult what's the status of this issue, did you resolve it?

No. I don't have any update. The pkcs11-tool --test is segfaulting for @NainKult, but without any backtrace or debug logs, it is hard to guess what went wrong or if it was resolved by the same fix as the #1134 pushed later (ECC support).

I was planning to purchase more CardOS 5.x chips to improve support but because of the Infineon chips thingy, I changed my mind. All my chips are in Operative Mode as of now and I have no way to test pkcs11-tool on a uninitialised chip (Manufacturing).

I can however confirm that #1134 solved the segfault on an initialized chip.

Statement from my card provider:

We would like to inform you of a potential security issue regarding all CardOS V5 products, which is related to RSA key generation based on the Infineon 'Asymmetric Crypto Library (ACL)' of the SLE78 chip platform. A researcher team [...] recently found a method to identify mathematical weaknesses of particular algorithms for prime number generation.

Thank you for confirmation. The uninitialized chips are not supposed to work with pkcs11-tool, though it should not segfault. So in case you will be able to reproduce the issue, please come back with findings.

I see that CardOS is clearly using Infineon chips and potentially their Fastprime library, but I did not find any official announcement about this issue from Atos confirming or declining what everything is affected in their case. You can always test the public keys on your own with the following tool: https://keychest.net/roca
I found only several references that 2048 and 4096 bit keys should not be affected (well .. they might be, but the complexity of the factorization should be still too expensive), which should be used already in any case.

Here is the complete and official Atos statement sent to their customers (me included). This document has been approved for public distribution.

According to your link, and for a 2048 RSA Key generated on one of my chips:
Test result | Subject to ROCA, insecure.

So in case you will be able to reproduce the issue, please come back with findings.

Wiiiiiiill dooooo ! (in Meeseeks voice)

I was able to use my Atos card, but only with Firefox and loading the module directly. Tokend/Safari/Chrome not working. Not sure about initializing a card.

@sgtstadanko Can you please elaborate how you achieved this? Thanks in advance