Sun Metaslot and my missing keystore

By Karen Tung on Jun 14, 2005

[VAF: This entry was transfered from Karen Tung's old Sun blog, due to its relevance to the Solaris Cryptographic Framework]

Since The Solaris Cryptographic Framework is integrated into Solaris 10, we have added some new features to the framework. One of these features is the Sun Metaslot, which will be generally available in the next Solaris Update release. In case you can't wait till the next Solaris Update to try out this exciting feature, this is also available since Solaris Express 2/05, and in Solaris Patch 118918.

The Sun Metaslot will greatly simplify the life of developers who write applications that uses PKCS #11. Now that Open Solaris is a reality, I can talk about the implementation of this new feature and clarify one question I often get from users who are used to using the framework the way it was in Solaris 10.

What is Sun Metaslot?

The Sun Metaslot is a new additional slot to the The Solaris Cryptographic Framework. It provides the virtual union of capabilities of all other slots in the framework. Instead of having to deal with many slots, an application can simply choose the Sun Metaslot, which have access to features of all slots currently plugged into the The Solaris Cryptographic Framework. It also does the tedious work of managing sessions and objects on different slots so an application can use the best slot for a particular mechanism without having to move objects and sessions back and forth. The Sun Metaslot behavior conforms to the PKCS#11 Standard. Applications should treat it as if it were any PKCS#11 slot with normal PKCS#11 semantics.

When you install the next Solaris Update release (or Solaris Express 2/05 or the patch), you will get the Sun Metaslot feature by default. There is no special configuration necessary. The Sun Metaslot is always presented as the first available slot in the The Solaris Cryptographic Framework. As such, if your application is written in such a way that it just uses the first capable slot to perform cryptographic operations for your application, your application will use the Sun Metaslot with no modification at all. If your application is very particular about the exact slot in which an operation is done, all slots in the originalThe Solaris Cryptographic Framework is available as usual except a minor catch, which I am going to explain below.

Why is one of my slots missing?

Ever since I gave the beta version of my Sun Metaslot implementation to other Sun internal engineers to try, I often get this question in my email. I am sure many of you might have exactly the same question. So, it's probably useful to explain it here for the last time, hopefully.

Here's the typical email:
I installed the Sun Metaslot feature into my test system, and everything seemed to work fine. However, when my application does a C_GetSlotList(), I found that the "Software RSA PKCS#11 softtoken" slot is missing. Is this a bug?

This is working as designed. When the Sun Metaslot feature is enabled, one visible difference you see on your system is the slot that is configured to provide persistent storage for "token" objects (aka keystore) is "hidden". The Sun Metaslot does not have its keystore. It uses the keystore from one of the actual slots. By default, Sun Metaslot is configured to use the "Software RSA PKCS#11 softtoken" slot, so, users will see that it is "missing".

The slot to be used as Sun Metaslot's keystore is configurable. See the cryptoadm(1M) command on how to configure a different keystore for Sun Metaslot.

During the Metaslot implementation, we found that making the keystore slot as one of the available slots will cause a problem with "object aliasing" between the Sun Metaslot and the keystore slot. If an application accesses the Sun Metaslot and the keystore slot at the same time, we won't be able to control the authentication state. For example, if the application first calls C_Login on the Sun Metaslot, Sun Metaslot will call keystore slot's C_Login(). Now, if the application makes the a sequence of a C_FindObject calls to retrieve the list of private objects from on the keystore slot, it will be able to successfully get the list. However, this is not the right behavior since the application hasn't done a C_Login to the keystore slot yet.

To prevent the above problem, we decided that it is best to hide the keystore slot. Even though an application won't be able to access the functionality of the keystore slot directly. All its functionality are still available via the Sun Metaslot.