EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Error opening storage

Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.
#22881
Posted: 12/18/2012 09:55:44
by Bernard L. (Premium support level)
Joined: 12/18/2012
Posts: 14

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:

Error opening storage: C:\<path>\Cryptoki.dll
PKCS#11 error CKR_ARGUMENTS_BAD in function C_GetSlotList
#22893
Posted: 12/18/2012 13:10:20
by Ken Ivanov (EldoS Corp.)

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).
#22917
Posted: 12/19/2012 02:27:13
by Bernard L. (Premium support level)
Joined: 12/18/2012
Posts: 14

Hi,

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?

Kind regards.
#22918
Posted: 12/19/2012 02:33:58
by Vsevolod Ievgiienko (EldoS Corp.)

Hello.

The driver that Innokentiy mentioned above is located in \EldoS\SecureBlackbox.NET\Extra\PKCS11ProxyDLL folder and is named as SecureBlackbox_PKCS11Proxy.dll

Quote
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?

The 9th version can be downloaded here: http://eldos.com/sbb/download-release.php
#22921
Posted: 12/19/2012 03:45:13
by Bernard L. (Premium support level)
Joined: 12/18/2012
Posts: 14

Hi,

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.
#22922
Posted: 12/19/2012 03:59:55
by Ken Ivanov (EldoS Corp.)

Bernard,

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.
#22923
Posted: 12/19/2012 07:04:24
by Bernard L. (Premium support level)
Joined: 12/18/2012
Posts: 14

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).

How would you solve this situation?
#22924
Posted: 12/19/2012 07:15:51
by Vsevolod Ievgiienko (EldoS Corp.)

You should simply put appropriate versions of SecureBlackbox_PKCS11Proxy.dll in the same folders where your executable files are located, but not to system folder.

Quote
Probably by following Windows priority of search order?

Yes. And according to this approach the first directory to search is the directory from which the application loaded.
#22925
Posted: 12/19/2012 07:42:34
by Bernard L. (Premium support level)
Joined: 12/18/2012
Posts: 14

It is not a executable, but a Windows service.

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 will see - we need to work on it a little now.

Thanks.
#22927
Posted: 12/19/2012 07:46:28
by Vsevolod Ievgiienko (EldoS Corp.)

The DLL name is hardcoded so another solution is to change it and recompile the latest SBB version.
Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.

Reply

Statistics

Topic viewed 3179 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!