Q: What is the Solaris Cryptographic Framework? A: It is a user and kernel space set of APIs (Application Programming Interfaces) and SPIs (Service Provider Intefaces) for providing software and hardware cryptographic algorithms to application and other kernel systems. Q: Does IPsec/Kerberos use the new Solaris Cryptographic Framework? A: Yes, and in doing so can take advantage of hardware acceleration, for IKE and for IPsec transport crypto. Same for Kerberos, both in userland in in kernel. Q: Does this implement any standards? A: Yes, the userland part of the framework implements the RSA PKCS#11 interface. The kernel space framework is modeled after PKCS#11 but differs in API and SPI to make it fit better with the needs of the Solaris kernel. Q: Will the SCF support cryptographic hardware accelerators? A: Yes it will. Cryptographic hardware accelerators will be supported in two ways: 1. Existing hardware that comes with its own PKCS#11 library may be plugged in directly to the userland part of the framework after the library has been signed. If this is done the accelerator will be available only to userland applications, such as IKE, Kerberos and many of the Sun Java Enterprise System products. 2. The Solaris Cryptographic Framework also adds a new set of DDI interfaces for the kernel. It will be possible to write a kernel driver for the hardware accelerator. Doing this will make it available for kernel cryptography consumers such as IPsec and NFS (when run over Kerberos). It also makes it available to all userland consumers of PKCS#11 as well, via pkcs11_kernel(5). At this time the kernel interfaces are not documented but we can provide the details and some support for those that are interested in writing a driver. Our intent is to make them documented in an update release of Solaris 10. Q: Will this Sun SCF be inegrated with the Sun ONE suite of products? A: Many of the Sun Java Enterprise System components can accept alternate cryptographic providers via PKCS#11. It is for this very reason that the userland API of the Solaris Cryptographic Framework is PKCS#11. The component products of the Sun Java Enterprise System may not be integrated with the Solaris Cryptographic Framework out of the box but those that use PKCS#11 can certainly be configured to use it. Over time we hope to have the Sun Java Enterprise System products using the Solaris Cryptographic Framework without requiring the administrator to do any special configuration. Q: Do you have plans to utilize a single cryptographics API across applications (native LDAP client, ssh, etc. )? If the toolkit is modular, this could prove to be very powerful. A: Yes that is our plan. As of the current Software Express releases for Solaris we have IKE, Kerberos, IPsec, and SASL using it. It is possible to use it for the SSL support in native LDAP as well but we haven't documented how to do this yet. Adding support to other applications is planned for future releases of Solaris. Q: Will this framework affect exporting Solaris to some regions/countries? A: No it will not. It was due to recent changes in US Export law that actually allowed us to implement this. This framework does not change the list of countries/regions to which Solaris can be imported. At this time the symmetric ciphers are limited to 128 bit key length due to import restrictions of some countries. There will be a Solaris Data Encryption Kit download/CD to increase that limit for those people who are allowed to import greater than 128 bit symmetric ciphers into their country. This has been made much easier than it was in the past due to the pluggable nature of the framework. Q: Does the Solaris Cryptographic Framework support the Elliptic Curve Cryptographic (ECC) System? How efficient is ECC compared to current public-key standards such as RSA? A: It supports it in the sense that PKCS#11 has mechanisms (recognized algorithm definitions) defined for it, so a developer could implement a plug-in provider offering ECC which the framework would make available to an application that knows how to use ECC. This is true both for userland PKCS#11 providers and for kernel drivers registering with the kernel part of the cryptographic framework. The providers we have implemented in userland and kernel do not provide ECC at this time. Because of the nature of the ECC approach to cryptography (using points on a curve) the key lengths used are much shorter than those used by asymmetric cryptographic algorithms like RSA. One side effect of these shorter key lengths is that it runs much faster with (theoretically) comparable strength. For the efficiency of ECC compared to RSA I would recommend reading academic papers on the subject. To avoid showing preference to any one survey I suggest doing the search yourself. Q: How does SCF work with Zones? A: Zones have access to the full capability of the Solaris Cryptographic Framework. More specifically it works like this: The userland part of the framework works exactly the same in a non global zone as it does in the global zone. Zones can add their own PKCS#11 providers to be used with libpkcs11 and can set their own policy for them using cryptoadm(1m). Zones can access the hardware providers registered with the kernel part of Solaris Cryptographic Framework as well. Only the global zone can set the policy and install/uninstall kernel cryptographic providers. At this time it means that all Zones can see all hardware providers For a future release we are investigating the possibility of adding per zone policy so that kernel hardware providers can be dedicated to specific zones. We are interested in any us cases you may have for this to feed our requirements. Q: In one question you answered YES to support for IPsec within SCF utilizing hardware accelerators, yet in a later question you answer this will possibly be available for IPsec if and when someone writes the kernel driver. Can you clarify this confusion? A: IPsec always uses the Solaris Cryptographic Framework for its encryption needs, even when no hardware is available. This is in contrast to previous Solaris releases where IPsec has its own encryption routines. If you wish to use a particular hardware accelerator with IPsec then you need a Solaris Cryptographic Framework driver for it. IPsec also has support for an offload capability, at this time this is only supported with Sun's SCA-4000 card. The difference here is that the adding/removal of the IPsec parts of the IP packet including the cryptographic operations happen on the SCA-4000 card. This is possible because the SCA-4000 card is both a cryptographic accelerator and a NIC. The SCA-4000 also has a persistent hardware keystore that can be used by IKE (via PKCS#11) to store the RSA private key(s). Hope this clarifies any confusion from my previous answers. Q: Does the SCF offer any type of compatibility with OpenSSL's API? A: Assuming you mean the EVP_ level interfaces in OpenSSL, PKCS#11 is similar to these but it is session based rather than sessionless. The obvious difference here is that with PKCS#11 you need to first establish a session with a given provider and it keeps all the state of the operation in that session (which may be completely inside a dedicated hardware resource). We have also implemented an OpenSSL Engine that uses PKCS#11. We intend to donate this engine back to OpenSSL. What this means is that out of the box on Solaris applications that use the RSA_, DSA_, DH_, RAND_ and EVP_ (for AES, DES, 3DES, RC4) will be using the algorithm implementations provided by the Solaris Cryptographic Framework via PKCS#11. For example if you have an SCA-1000 card it will come with just a kernel driver for Solaris 10. Once that driver is loaded it will be used by OpenSSL applications next time they startup. |
 | |||
 | |
