Why doesn't Aloaha Card Connector certificate "stick" on encrypted files?

Coordinator
Aug 13, 2007 at 5:03 AM
This question was left as a Comment on the Home page by engst03, so I copied it here instead.

Hi,

You are developing a very handy tool. Thank you very much for that!

Maybe you can answer me the following question?

We use the Aloaha Card Connector in our Environment. One great advantage is that it supports smart card based EFS (Even on XP, W2k3). Still so we experience the following problems.

  1. User encrypts file
  2. User manual removes encryption certificate from that file and assigns the smart card certificate. Additional the windows created encryption certificate is deleted from the store.
  3. User logs out and logs in.
  4. As soon user accesses the file the CSP asks for the smart card PIN and the file is accessible. Very good.

But now the problem. As soon the file is accessible Windows removes the smart card certificate, generates a new certificate and assigns that new certificate. So every time the user accesses the file he has to manually re-assign the smart card certificate.
Coordinator
Aug 13, 2007 at 5:20 AM
Edited Aug 13, 2007 at 5:24 AM

But now the problem. As soon the file is accessible Windows removes the smart card certificate, generates a new certificate and assigns that new certificate. So every time the user accesses the file he has to manually re-assign the smart card certificate.


This is the first I've heard of Aloaha's product, and it looks really intriguing. However, I can say with some authority (having worked with Microsoft's EFS team for a few years to understand the pre-Vista "no smartcards" limitation) that what Aloaha is trying to do is very challenging and will likely have many subtle issues.

The first problem (which they've apparently at least partially conquered) is the fact that until Windows Vista, EFS is hard-coded to always look for the Microsoft CSPs (Base and Enhanced). It was always said that there are no other CSPs that could be used with EFS (until Vista). The fact that Aloaha has been able to intercept the DPAPI call to ensure the LSA loads the smart card CSP (instead of one of the Base or Enhanced CSPs) is in itself a real feat. However, it sounds like there are other operations that it isn't able to properly intercept.

I would suggest trying the EFSCONFIGUPDATE application to ensure that Windows XP is actually configured to use the EFS certificate from the smart card. If Windows was configured to use another certificate for EFS, then that would certainly explain the behaviour you're seeing. (If the user has another CA-issued EFS certificate in their personal certificate store, then EFSCONFIGUPDATE may end up choosing that certificate rather than the Smart Card cert. To be sure that EFSCONFIGUPDATE chooses the smart card certificate, I would backup and then delete any other CA-issued certificates from the personal certificate store.)

I would also suggest confirming that the certificate on the smart cards actually contains the EFS EKU, so that the EFS component driver doesn't reject the certificate as "invalid" because the certificate doesn't meet the EFS driver's requirements (including having that EFS OID included in the cert).
Aug 18, 2007 at 12:37 AM
Hi,

thank you very much for taking that much time to answer my questions. But I think your assumptions are not right.

The CSP is of type "Microsoft Strong Cryptographic Provider" and does NOT intercept the DPAPI call. Its just a very clean CSP which solved the problem of the missing window handle.

Everything is configured fine. I even used your tools to check. There is no other EFS Certificate but Windows everytime creates a new one and replaces my smart card certificate with that new one.

My smart card certificate has the correct EFS EKU and OIDs set. To make sure it would be nice if you could post them here. There must be a reason why EFS rejects my cert as "invalid" and generates a new one as soon the EFS Data was decrypted with my smartcard.

Thanks a lot for your efforts!