Is OpenSC fully based on PC/SC or does it also use different commands?

Question

I am trying to learn the basics of smart card programming and I would like to add support for PKCS#11 to a card. The vendor does not provide any PKCS#11 module, so I would like to use OpenSC (the card is not listed as compatible with OpenSC).

As far as I know, the scenario should be this:

1. The software on the computer uses PKCS#11 APIs implemented by OpenSC.
2. OpenSC works together with PC/SC in order to build and send APDUs to the card.
3. The card processes the command APDUs and replies with response APDUs.

I need to know if will be enough to implement an applet that is able to recognize and process all commands specified by ISO-7816 or not.

In particular I can't figure out if the entire OpenSC implementation relies only on the commands specified by ISO-7816 or if it uses also particular commands (the fact that OpenSC is not compatible with all smart cards makes me think that it uses proprietary commands).

Answer 1

The biggest problem with writing such implementations is how and where data is stored on the card. While the data typed and commands for accessing them are indeed standardised in ISO-7816, commands for writing are not. Further, the cards vary greatly in which file types the allow and they are also often requiring proprietary extensions to standard ISO commands.

What OpenSC is doing is trying to create a PKCS#15 application on the card to use for the PKCS#11 access. If you cannot write that or the data is already present in a proprietary format, things can get very complicated.

Answer 2

the fact that OpenSC is not compatible with all smart cards makes me think that it uses proprietary commands

No, not really, it's rather the other way around. ISO 7816-4 lists many commands for file or record based smart cards. There are few if any cards that fully implement all the commands written in ISO 7816-4. Furthermore, even if they did, there are many gaps in the standard, such as not clearly describing error conditions, multiple options with regards even to what is at the "root" of the file system, proprietary parameters, proprietary commands, no clear secure messaging etc. etc. etc..

In that sense it is a horrible standard; you should see it as a poor attempt of the industry of file system card manufacturers to create something that they can all adhere to.

---

Supporting 7816-4 furthermore doesn't mean that any specific use case is supported. There are no descriptions on how you get to a signature. There is at least PKCS#15 (also reflected now as an ISO standard) which specifies where files and keys can be found. However, if you create a signature you also have to know what kind of signature is created and which command should be used to do that.

In other words, generally "middleware" such as OpenSC always has to do some stuff to support specific cards. That one card is not supported doesn't say that OpenSC is "wrong" in any way, it just means that support for the card - if it is indeed a file system card or programmable card - was not yet tested / implemented.

---

Note that PC/SC is just a standardized way of handling smart cards from within an operating system (starting with the Windows OS from which it originated). Those commands just have to have to comply with ISO 7816-4, but it doesn't care at all what kind of commands are send or in which order. There aren't any PC/SC compatible smart cards out there, there are only compatible readers (or, as they can not just read, smart card interface devices or IFD's) for ISO 7816-4 compatible smart cards.

Some hardware tokens may also be PC/SC compatible, simply because they emulate a combination of reader and chip or because they internally are a reader and chip (the cheaper / slower ones). Others work on a higher level and use PKCS#11 which defines an interface for cryptographic tokens directly and is arguably and objectively better defined than ISO 7816-4 or -15 combined.