StrongKey has been architected along the lines of one of the most ubiquitous, pervasive, and scalable services designed for 21st century Internet, the Domain Name Service (DNS). Just as DNS consists of a server daemon with its text database files and the name-service resolution library for clients, StrongKey consists of two primary components : a Symmetric Key Services (SKS) server and a Symmetric Key Client Library (SKCL).

Symmetric Key Services server

The Symmetric Key Services server (SKS) is a J2EE application that uses a relational database as its datastore. It uses a J2EE compliant application server for servicing client requests in three ways. One servlet services client requests for symmetric keys. Another services client requests for key-caching policy information, while a third servlet provides an administrative interface to the application.

Click on the following link Supported Databases and Application Servers to determine if your database/application server is currently supported by StrongKey.

Symmetric Key Client LIbrary

The SKCL is your application's interface to the SKS. It is supplied as a JAR file that can be used by your Java application to avail itself of symmetric key services. The SKS interface provides methods for acquiring symmetric keys, methods for encrypting, and decrypting data. In addition, methods for generating one-way message digests for applications, that do not need to use unencrypted data (also known as plaintext), but have a need to search databases based on the plaintext, are created.

Click on the following link for a quick look at the SKS interface to get an idea of what the methods look like.

Non-Java Applications

While the JAR file is directly accessible by Java applications, currently, non-Java applications can take advantage of this capability through "native modules". A C/C++ Dynamic Link Library (DLL) is available for the Windows platform, as well as an RPG module from IBM Lab Services for the iSeries (AS/400) platform. However, these modules are not open-sourced, but are available for commercial licensing through their respective vendors - StrongAuth and IBM.

Communications Protocol

The SKCL communicates with the SKS server using digitally signed Simple Object Access Protocol (SOAP) messages, which conform to OASIS' Web Services Security (WSS) standard. The digital signatures are used to enable "message-level security" which authenticate the requester as well as maintain the integrity of the message en route to the SKS server.

The SKS server responds to the SKCL with digitally signed SOAP responses as well. This is to ensure that SKCL clients are not spoofed into accepting keys from invalid servers on the network. The SKS server also encrypts the symmetric key using the SKCL client's encryption certificate using asymmetric-key cryptography. This ensures that the message can pass securely even over insecure networks without the use of IPSec, TLS or SSL. In addition, the encrypted message enables the secure caching of the symmetric keys on the client (if configured in your setup).

Security

Since StrongKey is a repository of symmetric keys, it stands to reason that the repository must be significantly secured against a breach. StrongKey ensures this in a number of ways:

 StrongAuth is in the process of building the policy rules for running the SKS server in a compartmentalized environment: specifically using Security Enhanced Linux (SE Linux). It is anticipated that the use of SE Linux for the SKS server will enhance the operating system security of the SKS server above the controls implemented already. In the meantime, StrongAuth recommends hardening the SKS server through traditional methods such as firewall, host-protection, locked cabinets, physical isolation, console logins, and other security measures.

Standards and Open-Source

StrongAuth believes very strongly about the use of industry standards, and in the open-source community. Consequently, StrongKey makes use of standards and open-source components profusely, wherever possible. Some of the security standards in used in StrongKey:

StrongAuth is in the process of submitting the XML-based SKCL-to-SKS protocol, to the Organization for the Advancement of Structured Information Standards (OASIS) for potential standardization on a royalty-free basis. This ensures that anyone can build their own standards-compliant symmetric key service clients and servers, if they choose to. Customer investments will not be locked into any specific vendor, including StrongAuth.

Building StrongKey from source

StrongKey is available in compiled and source-code distributions. For those who would like to build it from the source files, the following steps are a guide to the process. The same process may be used to build the application if you make modifications to the source code (yes, you can make your own modifications to the source if you wish. Please pay attention to the terms of the LGPL when you do so) or to build your own applications that link into the SKCL.

StrongKey was developed using NetBeans 5.0, so this process is tailored towards the specific IDE. In time, StrongAuth will release an Eclipse-based distribution; until then, if you are an Eclipse user, please feel free to experiment with the build.xml script. We will appreciate any suggestions and source contributions towards that, if your interest is piqued in this software. Please see the community Forums section of this website for how to participate in this effort.