We are sure the right dll is being used, because in Visual Studio we refer to it explicitly, and if we don't do it right, we get a version error. So that part has been solved already. It is with the right dll that we get the error:

The driver DLL is not referenced in the Visual Studio; it has no version and it can be easily spotted in System32 folders when upgrading the product. Please re-check that no copies of older driver DLL remain in the system in problem; the correct driver DLLs should have the sizes of 723816 bytes (x86 version) and 1234792 bytes (x64 version).

Not sure what dll you are talking about - Cryptoki.dll certainly has a version number, and it has a different size:

Version 3.32.0.0
Date 16/05/2008 1 :53 :00 PM
Company SafeNet Inc.

We build the application with the version 10.0.230, and indeed, the SBB dll's are next to the executable.

If I replace the dll by another version (10.0.228) ,I receive an error saying the assembly 10.0.230 cannot be found.

We currently test a migration from version 6 to 10, we cannot remove the dll version 6 because it is also being used (for backward compatibility reasons). This is why we put the dll next to the application.

PS. Can we download a SBB version 9 somewhere to do some testing? We have to say we bought version 10 recently, but a test with version 9 might be helpful perhaps?

Thanks for the information. We did some more investigation and we also tested with V9 now.

Let me try to clear up the issue a bit:

1. We do NOT use the SecureBlackbox_PKCS11Proxy.dll, we use cryptoki.dll (Safenet HSM). We select this dll (File/open storage/ select cryptoki.dll) so there is no way it would work with your Proxy dll. The keys are not stored on the local machine, we need to connect to a remote, secure store.

2. What we observe is that even when testing with CrypoTokenDemo_V09 (we just tested this today after downloading this version), it works perfectly. With CrypoTokenDemo_V10 however we get the error as we indicated before. So from our point of view this really looks like a bug in SBB version 10.

SecureBlackbox_PKCS11Proxy.dll is used as a 'proxy layer' between managed SecureBlackbox components and unmanaged PKCS#11 driver (cryptoki.dll in your case). The proxy DLL is *always* used whenever SecureBlackbox needs to access a PKCS#11 driver; the components do not access HSM drivers directly for the sake of compatibility and stability. This way, if the components did work for you as some stage in time, the proxy DLL had been definitely in use.

I guess that you have an older version of the proxy DLL installed in the System32 folder (belonging to version 9 of SecureBlackbox or to an earlier version). Once you replace this proxy DLL with an up-to-date one from SecureBlackbox 10 distribution, the latter will work for you as well.

Okay, this was very helpful. After some testing (with renaming the SecureBlackbox_PKCS11Proxy.dll) it turns out it is being used indeed. And it works with the newer version of the *Proxy.dll.

The problem now is, we have several applicatins using SBB on a single server, and they all use version 6 of SBB. Now we need version 10 for another project, using secure keys in a completely different context (sending AS2 messages). It would be very tough to re-test and/or adapt other projects who need to use the secure key store in other contexts (such as signing pdf documents). Which means we somehow need the older *proxy.dll to be used by the other applications, and the newer version by our new project.

At this moment we don't even know how SecureBlackbox_PKCS11Proxy.dll is being found by SBB. Probably by following Windows priority of search order? In any case it seems like we have a problem now because the new SecureBlackbox_PKCS11Proxy.dll is not backward compatible with older versions - which means a massive upgrade of multiple applications would be required. Except if there is a way to tell an application using SBB v10 to use a different SecureBlackbox_PKCS11Proxy.dll (e.g. one which is stored in specific folder).

We will look further into this now, how to solve it, but even if we put the dll in our project, I'm not sure the service will find that dll first. And if it does, we have a management problem because whenever we install a project, we need to choose the right dll. In other words, such a situation is always awkward to work with.

If this doesn't work as expected there will be a problem. To my understanding once a dll is loaded in memory, Windows will not search for the dll - it will see the dll in memory (based simply on the modulename, the so-called "KnownDLLs" in the registry). So as far as I see the risk of a typical version-related issue (or non-backward compatibiity issue) is very real.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.