Skip to main content
Added information about tls clientAuth with smart cards
Source Link

From your question it looks like you ask for PKI smart cards only, so I will skip other types of smart cards.

Some theory first. Computers talk to all smart cards using APDU commands. They are really low level interface and are mostly different for all cards. There are practical and political reasons for this. Practical reason is that every card can have specific functionality that is hard to standardize. Political reason is that smart card vendor do not want clients to be able to easily change cards with cheaper one from other manufacturer. But for smart card to be usable, there must be standard API. So every vendor provides middleware that exports standard APIs (PKCS#11, CryptoAPI, TokenD) and translates this high level function calls to series of APDU commands. As this is not so easy task, all proprietary middlewares have bugs. There was many attempts for unified smart card interface or specification, but all of them failed, because vendors continued to create and sell proprietary cards.

As for standards/projects:

  • ISO/IEC 24727 - I did not have personal experience with this standard, but it looks like another failed attempt for API standardization. As all of them it has very limited adoption. I think only Giesecke & Devrient created cards that implements it.
  • ISO 7816-4 - This standard defines low level commands for some card operations like select file and read binary, but it do not cover more usable commands like signing or key generation.
  • PKCS#11 - From Wikipedia - The PKCS #11 standard defines a platform-independent API to cryptographic tokens. There are many applications that can use PKCS#11 interface and is only smart card interface that Mozilla supports, so every PKI smart card has middleware that implements it. Usually not all functions are implemented and some are implemented in not standard way. It looks like middleware vendors test their implementation only with Firefox, and there is no guarantee that other PKCS#11 applications will work correctly.
  • PKCS#15 - Another attempt to fix proprietary middleware problem. I have never used it and AFAIK there is no major software that uses it.
  • open eCard - it do not mater as no card implement it.
  • OpenSC - this is open source middleware for many different cards. Some companies have written and actively support OpenSC drivers for their cards, some card drivers are written based on public specification and some are reverse engineered. Most of cards with public specification are national eID cards like IAS-ECC or US PIV card. Some small companies like Aventra are published their APDU commands too.

About smart card use in browsers - all major browsers can use certificates stored on smart card for SSL client authentication.

ActiveX, Java applets or browser extensions are used for legally binding signatures, as no browser has integrated support for them. There was some attempts to add needed functionality to WebCryptoAPI, but it looks like browser vendors are against it. You can read this discussion for details - http://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/. So I do not believe that signing document in browser without additional plugins or add-ons will be possible in near future.

Edit:

For TLS clientAuth to work with smart card, without additional installation, operating system or browser must include smart card middleware.

I think that Windows comes with some smart card middleware preinstalled, but many different cards have their middleware in windows update, and it is installed automatically when card is plugged in. This way client authentication will work with all modern browsers except Firefox. As Firefox do not use standard Windows crypto interface (CryptoAPI) it needs additional installation or at least manual configuration.

Older versions of OS X also included support for some cards, but it was removed after 10.6.

From your question it looks like you ask for PKI smart cards only, so I will skip other types of smart cards.

Some theory first. Computers talk to all smart cards using APDU commands. They are really low level interface and are mostly different for all cards. There are practical and political reasons for this. Practical reason is that every card can have specific functionality that is hard to standardize. Political reason is that smart card vendor do not want clients to be able to easily change cards with cheaper one from other manufacturer. But for smart card to be usable, there must be standard API. So every vendor provides middleware that exports standard APIs (PKCS#11, CryptoAPI, TokenD) and translates this high level function calls to series of APDU commands. As this is not so easy task, all proprietary middlewares have bugs. There was many attempts for unified smart card interface or specification, but all of them failed, because vendors continued to create and sell proprietary cards.

As for standards/projects:

  • ISO/IEC 24727 - I did not have personal experience with this standard, but it looks like another failed attempt for API standardization. As all of them it has very limited adoption. I think only Giesecke & Devrient created cards that implements it.
  • ISO 7816-4 - This standard defines low level commands for some card operations like select file and read binary, but it do not cover more usable commands like signing or key generation.
  • PKCS#11 - From Wikipedia - The PKCS #11 standard defines a platform-independent API to cryptographic tokens. There are many applications that can use PKCS#11 interface and is only smart card interface that Mozilla supports, so every PKI smart card has middleware that implements it. Usually not all functions are implemented and some are implemented in not standard way. It looks like middleware vendors test their implementation only with Firefox, and there is no guarantee that other PKCS#11 applications will work correctly.
  • PKCS#15 - Another attempt to fix proprietary middleware problem. I have never used it and AFAIK there is no major software that uses it.
  • open eCard - it do not mater as no card implement it.
  • OpenSC - this is open source middleware for many different cards. Some companies have written and actively support OpenSC drivers for their cards, some card drivers are written based on public specification and some are reverse engineered. Most of cards with public specification are national eID cards like IAS-ECC or US PIV card. Some small companies like Aventra are published their APDU commands too.

About smart card use in browsers - all major browsers can use certificates stored on smart card for SSL client authentication.

ActiveX, Java applets or browser extensions are used for legally binding signatures, as no browser has integrated support for them. There was some attempts to add needed functionality to WebCryptoAPI, but it looks like browser vendors are against it. You can read this discussion for details - http://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/. So I do not believe that signing document in browser without additional plugins or add-ons will be possible in near future.

From your question it looks like you ask for PKI smart cards only, so I will skip other types of smart cards.

Some theory first. Computers talk to all smart cards using APDU commands. They are really low level interface and are mostly different for all cards. There are practical and political reasons for this. Practical reason is that every card can have specific functionality that is hard to standardize. Political reason is that smart card vendor do not want clients to be able to easily change cards with cheaper one from other manufacturer. But for smart card to be usable, there must be standard API. So every vendor provides middleware that exports standard APIs (PKCS#11, CryptoAPI, TokenD) and translates this high level function calls to series of APDU commands. As this is not so easy task, all proprietary middlewares have bugs. There was many attempts for unified smart card interface or specification, but all of them failed, because vendors continued to create and sell proprietary cards.

As for standards/projects:

  • ISO/IEC 24727 - I did not have personal experience with this standard, but it looks like another failed attempt for API standardization. As all of them it has very limited adoption. I think only Giesecke & Devrient created cards that implements it.
  • ISO 7816-4 - This standard defines low level commands for some card operations like select file and read binary, but it do not cover more usable commands like signing or key generation.
  • PKCS#11 - From Wikipedia - The PKCS #11 standard defines a platform-independent API to cryptographic tokens. There are many applications that can use PKCS#11 interface and is only smart card interface that Mozilla supports, so every PKI smart card has middleware that implements it. Usually not all functions are implemented and some are implemented in not standard way. It looks like middleware vendors test their implementation only with Firefox, and there is no guarantee that other PKCS#11 applications will work correctly.
  • PKCS#15 - Another attempt to fix proprietary middleware problem. I have never used it and AFAIK there is no major software that uses it.
  • open eCard - it do not mater as no card implement it.
  • OpenSC - this is open source middleware for many different cards. Some companies have written and actively support OpenSC drivers for their cards, some card drivers are written based on public specification and some are reverse engineered. Most of cards with public specification are national eID cards like IAS-ECC or US PIV card. Some small companies like Aventra are published their APDU commands too.

About smart card use in browsers - all major browsers can use certificates stored on smart card for SSL client authentication.

ActiveX, Java applets or browser extensions are used for legally binding signatures, as no browser has integrated support for them. There was some attempts to add needed functionality to WebCryptoAPI, but it looks like browser vendors are against it. You can read this discussion for details - http://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/. So I do not believe that signing document in browser without additional plugins or add-ons will be possible in near future.

Edit:

For TLS clientAuth to work with smart card, without additional installation, operating system or browser must include smart card middleware.

I think that Windows comes with some smart card middleware preinstalled, but many different cards have their middleware in windows update, and it is installed automatically when card is plugged in. This way client authentication will work with all modern browsers except Firefox. As Firefox do not use standard Windows crypto interface (CryptoAPI) it needs additional installation or at least manual configuration.

Older versions of OS X also included support for some cards, but it was removed after 10.6.

Source Link

From your question it looks like you ask for PKI smart cards only, so I will skip other types of smart cards.

Some theory first. Computers talk to all smart cards using APDU commands. They are really low level interface and are mostly different for all cards. There are practical and political reasons for this. Practical reason is that every card can have specific functionality that is hard to standardize. Political reason is that smart card vendor do not want clients to be able to easily change cards with cheaper one from other manufacturer. But for smart card to be usable, there must be standard API. So every vendor provides middleware that exports standard APIs (PKCS#11, CryptoAPI, TokenD) and translates this high level function calls to series of APDU commands. As this is not so easy task, all proprietary middlewares have bugs. There was many attempts for unified smart card interface or specification, but all of them failed, because vendors continued to create and sell proprietary cards.

As for standards/projects:

  • ISO/IEC 24727 - I did not have personal experience with this standard, but it looks like another failed attempt for API standardization. As all of them it has very limited adoption. I think only Giesecke & Devrient created cards that implements it.
  • ISO 7816-4 - This standard defines low level commands for some card operations like select file and read binary, but it do not cover more usable commands like signing or key generation.
  • PKCS#11 - From Wikipedia - The PKCS #11 standard defines a platform-independent API to cryptographic tokens. There are many applications that can use PKCS#11 interface and is only smart card interface that Mozilla supports, so every PKI smart card has middleware that implements it. Usually not all functions are implemented and some are implemented in not standard way. It looks like middleware vendors test their implementation only with Firefox, and there is no guarantee that other PKCS#11 applications will work correctly.
  • PKCS#15 - Another attempt to fix proprietary middleware problem. I have never used it and AFAIK there is no major software that uses it.
  • open eCard - it do not mater as no card implement it.
  • OpenSC - this is open source middleware for many different cards. Some companies have written and actively support OpenSC drivers for their cards, some card drivers are written based on public specification and some are reverse engineered. Most of cards with public specification are national eID cards like IAS-ECC or US PIV card. Some small companies like Aventra are published their APDU commands too.

About smart card use in browsers - all major browsers can use certificates stored on smart card for SSL client authentication.

ActiveX, Java applets or browser extensions are used for legally binding signatures, as no browser has integrated support for them. There was some attempts to add needed functionality to WebCryptoAPI, but it looks like browser vendors are against it. You can read this discussion for details - http://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/. So I do not believe that signing document in browser without additional plugins or add-ons will be possible in near future.