locked
Process flow for "Run As Other User" and using certificates from a smart card RRS feed

  • Question

  • I have written a virtual smart card driver (KMDF) that in most cases works.  I have been able to use many different tools to read the card data from the virtual driver.  I am even able to use the virtual reader to logon in a SC enabled domain.

    I have however run into the following issue.  If I have a physical reader on the system, and I have my virtual reader installed, when I attempt a "Run As Other User" option it will fail if I select a certificate from my virtual driver.  If I run the same test where my virtual reader is the only SC on the system it will work.  If I run the same test using two physical readers on the system it will work.  All tests are performed using the same set of smart cards.

    When it fails I will get a CAPI2 event log error stating that CryptAcquireCertificatePrivateKey failed to find a container.  I have been looking into this for about 4 weeks now and can not find a legitimate reason for it.  Given that this test works with two physical readers, I keep going back to my driver trying to determine if there is something that I am not doing that could cause the problem.

    I have used the vendor tools for reading/managing the cards, and a host of other tools and with all of them I am able to work with the card data through the virtual reader driver.

    One thing I have found is that after the virtual reader is created, and the certs are copied to the current users cert store, if I change the container name in the cert context to be Type I (\\.\[reader name]\[container name]) this test will succeed.

    I have examined and verified every avenue of reader / card enumeration I can think of and have not seen anything wrong.  I have also verified that when selecting the cert to authenticate for the other user, the other users store does not come into play as one might presume.  The cert does appear to be first read from the current user store.  The process flow just seems to not be able to enumerate the containers on the virtual reader.

    One area I have been looking into is that if I create the virtual reader first, then add a physical reader to the system this scenario works.  This is was keeps leading me down the path of how the readers/active cards are enumerated during this process.

    If anyone has any ideas I would love to hear them.

    Friday, June 1, 2012 6:31 PM

Answers

  • Try to call MS Product support.  If this is a bug, you'll get a solution + money back.

    If it is a "Windows feature, working by design" (what most of us still call a bug) you'll get only a solution.

    [ by the way... "\\.\reader name" looks like a device name. Can the device  name of your reader be local in the user's session, or something like that? ]

    -- pa


    Friday, June 1, 2012 10:30 PM
  • I looks like I have solved this issue.

    It came down to an implementation within our driver.  When we were setting up the Reader Capabilities structure we chose to retain the vendor name of the physical reader, and set the IFD Type to something custom.  This unto itself does not cause an issue, but add in the following...

    We set the Reader Type to VENDOR (or Unknown) and based on documentation set the Channel ID to 0 since it was documented as not used for Vendor Type.  Turns out that is not quite correct.  In the failure scenario we would end up with two readers, both having the same Vendor Name, a different IFD Type, a different Reader Type, but the same Channel ID.  This is where the problem started.

    Then the underlying CryptoAPI layer was trying to determine which reader was which they both looked the same; hence the issue of same name and same Channel ID.  This is further supported by the fact if we added our virtual reader first, then added the same physical type of reader to the system it would work since our driver was first in the list.

    I have since changed our driver to use a Vendor Name to represents our company, and set the IFD Type to a value the allows a visual relationship back to to the physical reader, and set the channel id to the FDO instance number (just to ensure its unique in case we create more than one virtual reader).

    I doubt we would have ever seen this if we had set the vendor name, perhaps correctly?, to something that represents our company.  I am also not sure anyone could/will benefit from this, but I am posting it since one never knows.

    I am however still trying to understand by why other attributes like Reader Type are not used when trying to isolate an individual reader.  Which it might be just not for type Unknown.  I might try looking at the source for PSCS lib or PCSC-lite lib in search of an answer.

    Tuesday, June 5, 2012 7:52 PM

All replies

  • I am taking one last stab at finding the problem this weekend.  I have setup a win 7 debug build system and will be stepping through lsasss under this scenario to see if I can get a better understanding of what exactly is going on.  The one point that is driving me crazy is that this same scenario with two physical readers works.  So that has lead me to believe there is something wrong in my driver, but when everything else works with the driver I just can not pin point what the issue would be.

    If I don't find an answer by Sunday I will be submitting a support ticket with MS.  I hit a road block like this in the past and had to engage them.  It was worth the money, and at this point I will gladly pay for an answer.  I got teamed up with a really knowledgeable dev.

    the name does look like a device name, but I think it is just coincidence.  This is one of the 4 types of naming conventions.  Strangely in a reply on another site I had a dev from MS state that MS does not really support Type I convention.

    I am sure this has to do with something strange feature I have not implemented in the driver.  I will be sure however to post the answer here so others can benefit should they find themselves in this strange little situation.

    Saturday, June 2, 2012 2:53 AM
  • I looks like I have solved this issue.

    It came down to an implementation within our driver.  When we were setting up the Reader Capabilities structure we chose to retain the vendor name of the physical reader, and set the IFD Type to something custom.  This unto itself does not cause an issue, but add in the following...

    We set the Reader Type to VENDOR (or Unknown) and based on documentation set the Channel ID to 0 since it was documented as not used for Vendor Type.  Turns out that is not quite correct.  In the failure scenario we would end up with two readers, both having the same Vendor Name, a different IFD Type, a different Reader Type, but the same Channel ID.  This is where the problem started.

    Then the underlying CryptoAPI layer was trying to determine which reader was which they both looked the same; hence the issue of same name and same Channel ID.  This is further supported by the fact if we added our virtual reader first, then added the same physical type of reader to the system it would work since our driver was first in the list.

    I have since changed our driver to use a Vendor Name to represents our company, and set the IFD Type to a value the allows a visual relationship back to to the physical reader, and set the channel id to the FDO instance number (just to ensure its unique in case we create more than one virtual reader).

    I doubt we would have ever seen this if we had set the vendor name, perhaps correctly?, to something that represents our company.  I am also not sure anyone could/will benefit from this, but I am posting it since one never knows.

    I am however still trying to understand by why other attributes like Reader Type are not used when trying to isolate an individual reader.  Which it might be just not for type Unknown.  I might try looking at the source for PSCS lib or PCSC-lite lib in search of an answer.

    Tuesday, June 5, 2012 7:52 PM