|
Client Modules Server Modules Client Mechanics Server Mechanics StrongKey is an open-source Symmetric Key Management System (SKMS) whose primary objective is to manage the generation, escrow, recovery and issuance of symmetric encryption keys across an enterprise. It is an enterprise-scale application based on the Java 2 Enterprise Edition (J2EE) 1.4 architecture and takes advantage of the benefits provided by J2EE: scalability, availability, portability and security. This document provides an explanation of how StrongKey works, so that evaluators of the software who are trying to understand how it works, and developers who either intend to integrate their applications with it or extend StrongKey, can understand the mechanics of the application. Knowledge of Java, J2EE and cryptography is essential to understanding StrongKey. Footnotes at the end of this paper provide reference material to the reader that may find useful. The document will refer to this picture as the “How-it-works” picture in the rest of this document. It provides a birds-eye view of the mechanics of StrongKey.
Client Modules StrongKey clients can be any device or application that supports Java SE 1.5 or above. The current release was designed to work on laptops, desktops and servers; however, with adaption, it can run on smaller devices such as PDAs and embedded devices, such as printers, routers, etc. The client side library of StrongKey is the Symmetric Key Client Library (SKCL) and is delivered as a JAR file called skcl.jar. The SKCL is responsible for providing an interface to client applications (such as xenc in the above diagram) so the application may avail services from the SKMS. It has a Symmetric Key Service (SKS) interface implemented by the SKSImpl class and provides methods for getting a symmetric key, encrypting plaintext, decrypting ciphertext and generating Message Digests based on the Secure Hashing Algorithm (SHA). SKSImpl uses the utilities.jar module for functions such as identifying all SKS servers configured on the client, logging and retrieving properties from resource bundles, which are relevant to the client's configuration and for internationalization. SKSImpl also uses one or more configured Java Cryptography Extensions (JCE) Providers to interact with cryptography libraries and modules that store and use cryptographic keys. The Crypto Token may be hardware modules such as smartcards, Trusted Platform Module (TPM) chips and/or USB-style cryptographic tokens. For client machines that are servers – such as database servers, application servers, etc. - the cryptographic token may also be a Hardware Security Module (HSM) that can be used for acceleration of cryptographic operations and/or secure storage of the keys. Xenc is a client-side application, included in StrongKey, that is provided as a sample application to show how it uses the SKCL. It can perform file, directory and column-level database encryption using Triple-Data Encryption Standard (3DES) and the Advanced Encryption Standard (AES) keys/algorithms. Server Modules On the server side, StrongKey must be deployed on a J2EE compliant application server with a Relational Database (RDBMS) for storage of StrongKey data. Currently, StrongKey has been tested to work with the Sun Java System Application Server (SJSAS) and the JBoss Application Server. See the Supported Platforms link to learn about the specific version numbers of the supported products. StrongKey has been tested with the MySQL database, but can work with any RDBMS with some minor modifications to the schema Data Definition Language (DDL). The StrongKey server implements the Model-View-Controller (MVC) architecture, and delivers the application in distinct modules corresponding to the MVC architecture. The Model layer is implemented in the entitybean module that consists of Container Managed Persistence-Enterprise Java Beans (CMP-EJB). The View layer is implemented in multiple servlets – the Symmetric Key Service (SKS) servlet, the KeyCachePolicy (KCP) servlet and the Java Server Faces (JSF) servlet. The first two servlets are delivered in the servlet module, while the JSF servlet is delivered in the gui module. Finally, the Controller layer is implemented as Session Enterprise Java Beans and delivered in the txbean module. One of the most important components of the server is the servlet that clients interact with. Within StrongKey, it is the Symmetric Key Service (SKS) servlet, delivered in the servlet module of the application. It is responsible for receiving all requests for new or existing symmetric keys, and responding to them. The KeyCachePolicy (KCP) servlet is responsible for receiving requests for key-caching policy information from clients and responding to them. Key-caching is essential for client applications to continue performing encryption and decryption when the SKS server is unavailable. The Administration Console is delivered as a distinct Java Server Faces (JSF) servlet and web-pages in the gui module. This is the only module in StrongKey that has a graphical user interface. While any client on the network can connect up to the SKS and the KCP servlets, connecting to the JSF servlet requires a digital certificate for establishing a Client Secure Socket Layer (Client SSL) session with the servlet. Without an authorized digital certificate, the JSF servlet does not permit establishment of connections to the console. Besides the SKS servlet, the other workhorse of StrongKey is the txbean module, that consists of stateless-Session Enterprise Java Beans (EJB). Each transaction in StrongKey is represented by a single class file. The jaxb module consists of classes to convert Java objects into eXtensible Markup Language (XML) representations, and vice-versa. The jaxb module is used by the txbean module for creating and validating XML Signature objects when storing and retrieving objects to and from the database, respectively. The databean module implements Data Transfer Objects (DTO), and are used to strictly carry data between different layers of the server application. They do not implement any business logic, and serve purely as containers for transport. The utility module consists of general purpose classes to assist with common functions used by all modules of the StrongKey application. Client Mechanics When a client (such as xenc) needs a symmetric key, it instantiates an SKS object and calls one of the methods to get a symmetric key. It need not know what type of symmetric key, nor where to get it. However, it must provide authentication information to a JCE Provider keystore containing a Digital Certificate that identifies the application, along with the Private Key associated with the application. This digital certificate must be capable of signing and data encryption (or the application must have two digital certificates, each enabled for the individual purpose). The implementation of the SKS object (SKSImpl) first authenticates the client with the supplied credential (the certificate Distinguished Name (DN)) and password (to the JCE keystore) by attempting to access the keystore and locate the digital certificate with the supplied DN. If authenticated, SKSImpl checks the identifier of the symmetric key requested by the client application. The identifier – the Global Key ID (GKID) – in StrongKey 1.0 consists of the concatenation of the SKS Server ID and the unique Key ID generated on that server. With this concatenation, each key is uniquely identified within an enterprise SKMS. Examples of GKID are: 0-0, 1-13, 3-211, 5-9371, etc. The 0-0 GKID is a special GKID that indicates to SKSImpl and the SKS server, that a new symmetric key is being requested. The SKS server assigns the GKID to a key, after it has been generated and escrowed. If the client is configured to check the local cache first, SKSImpl checks its key-cache for an unused (new) symmetric key. If one exists, SKSImpl reads in the symmetric key, validates the digital signature on the key (using the certificates configured in its keystore) and then decrypts the symmetric key using the appropriate Private Key from its keystore). It then creates a Symkey object and hands it to the application. The application may either choose to perform the cryptographic operation itself, or have the SKSImpl library preform the operation. If the client is configured to go to the network first for symmetric keys, or if there isn't a new symmetric key in its cache, SKSImpl constructs a SOAP object with a SymkeyRequest in it, digitally signs it and sends it to the first SKS server configured in its list of SKS servers. If it cannot reach the server for any reason, it tries the next SKS server on its list, until it either gets a response of some kind, or has exhausted all SKS servers on its list. In the latter case, SKSImpl responds to the application with an error. If the request is successfully sent to the server, the thread blocks and waits until there is a response from the server. If it gets a SOAPFault message, it extracts the fault message and responds to the application with it. If it gets a SymkeyResponse message – indicating a successful response to the request – it validates the response from the server and then based on the locally configured KCP, it may cache the key locally. It then decrypts the symmetric key with the appropriate Private Key, creates a Symkey object and returns it to the client application. The mechanics for getting an existing key is almost identical. The difference is that the client application must know the GKID it needs. This is typically stored with the ciphertext in the application's database, or within the ciphertext file if using a standard such as XML Encryption. With the known GKID, the client makes the same call to the implementation of the SKS interface. SKSImpl, after authenticating the client application, recognizes that the request is for an existing key, and based on the local KCP, it checks its cache for the key. If the key exists locally, it reads the object, verifies its integrity, decrypts the key and hands it to the application. If it doesn't exist locally, it attempts to get the key from an SKS server. The protocol for getting an existing symmetric key from an SKS server is identical to that of getting a new symmetric key – the only difference is the value of the GKID in t he request. The SKCL also makes requests to the KCP servlet on any configured SKS server on the network using an implementation of the KCP interface (KCPImpl in the SKCL). KCPImpl goes through the almost identical process as SKSImpl in communicating with t he SKS server using signed SOAP messages and receiving signed SOAP responses. It is interesting to note that the protocol for a KCPRequest is an empty request. Since the header of the SOAP object is digitally signed using the Private Key of the client's authentication certificate, the KCP servlet needs no other information to lookup and return the key-caching policy that applies to that client. Server Mechanics This document does not discuss the installation, deployment and configuration of the StrongKey Enterprise Archive (EAR) file; portions of this process are discussed in the Installation documents on the StrongKey website. When the J2EE container containing the StrongKey EAR boots up, all the EJBs are automatically loaded by the container and accessible through the Java Naming and Directory Interface (JNDI). The three servlets – SKS, KCP and the JSF-based administration servlet – are also automatically started by the container. When the SKS servlet starts up, it ensures that it can find all the EJBs from the txbean module, the default KeyUsePolicy (KUP) object for assigning policies to new symmetric keys, if specific KUPs do not apply to the requesting client, sets up all the cryptographic objects and framework factories that it needs, and starts listening for requests. When the SKS servlet receives a request, it performs the following 12 tasks: It parses the GKID in the request; it needs to do this before validating the request for logging errors; It acquires the next Request ID for audit purposes and assigns it to the request; It creates a SymkeyRequestDatabean (SRDB) for transferring data from the servlet to the appropriate transaction EJB; it creates a local SKSBean for transporting local parameters conveniently between the servlet and its static helpers; It creates the SOAP framework for validating the request; It verifies the SymkeyRequest; it extracts the requester's information from the signed SOAP header and validates this against the StrongKey database; It determines the requester's authorization for the requesting that specific GKID. Even if the requester is requesting a new symmetric key, this must still be authorized in the StrongKey database; if the request is for a new key, it checks for a KUP for this requester and any group that this requester belongs to. If a specific, and valid, KUP applies to this requester, it is used. If there isn't a specific KUP for this requester, but the requester is part of a group and a group KUP applies, then it uses the group KUP. If no group KUP applies, it uses the default KUP that applies system-wide; if the request is for an existing key, the servlet checks for a KeyGrant that applies either for the requester or a group that the requester belongs to. If a specific or a group KeyGrant does not exist, the request is rejected and logged. If a KeyGrant exists, then, The existing symmetric key is extracted from the database; If the requester is not the same requester who originally caused the creation of the key, the key is decrypted by the servlet and re-encrypted for this specific requester; The KUP that applies to this key is retrieved from the database; the symmetric key and its KUP are embedded into a SymkeyResponse, packaged into a SOAP message, secured and returned to the requester. If the request is for a new key, it generates a symmetric key based on the KUP it retrieved in step 9' It encrypts the newly generated symmetric key for escrow; Creates a new SymkeyDatabean object; Calls a session EJB and saves the SymkeyDatabean. The EJB, in turn, verifies all data, converts the Java object to an XML representation, digitally signs the XML and adds the XML Signature to the SymkeyDatabean and hands it to a CMP-EJB for storage in the database; The SRDB is updated with with information about the newly generated symmetric key; It saves the SRDB in the database; Creates the SOAP response with t he new symmetric key and KUP information; Secures the response by digitally signing it (and optionally encrypting it – although this is not really necessary since the actual symmetric key is already encrypted with the recipients' Public Key of its Encryption certificate (which is in the database) – and returns the response to the requester;
Throughout this process, the servlet is capturing information into the SRDB and logging information in the application servers' logs. Every object the servlet requests from the database (through a get.. EJB), is automatically verified for integrity before being returned to the servlet as a databean. The KCP servlet undergoes a similar process – all messages received by the servlet must be digitally signed SOAP messages and all responses are digitally signed SOAP responses. However there are some differences in that the servlet only needs to know if a specific KCP applies to the requester; if it does, it is returns the specific KCP. If there is no specific KCP, but a group KCP applies, it returns the first group KCP that applies to the requester (a requester could be in multiple groups where a different KCP applies to each group). If no group KCP applies to the requester, then the default KCP is returned; this applies to the entire SKMS. The JSF-based servlet for the Administration Console is similar, except that it expects a Client SSL session to connect up to it, with a valid Client SSL digital certificate used for authenticating the client session. The client SSL certificate also establishes the role that the client has within the application. If the client session is deemed authorized, the user sees the GUI web-console, with the appropriate actions highlighted for their role. All requests submitted to the servlet cause the creation of a databean from the form elements. The servlet then calls the appropriate session EJB, which are implemented as add<Object>, update<Object>, or get<Object> type EJBs, and calls their execute() method, passing them the databean with the form data. The EJB performs its validation checks on the databean, and executes the transaction. All ADD and UPDATE transactions generate XML representations of the databean through the jaxb module, and an XML Signature that is then added to the databean before being handed to the appropriate CMP-EJB for storage in the database. Update transactions automatically cause the creation of a <Object>HistoryDatabean which is stored in a history table for that object. The signed history objects are used to establish an audit trail of changes to objects. All GET transactions automatically verify the XML Signature on the object before creating a databean and returning to the appropriate servlet. The XML Signatures are created by a signXML session EJB and validated by the validateXML session EJB. These two EJBs have access to preconfigured JCE Providers and hardware security modules, if any. Properties in the language-specific resource bundle (symkey_<LANG>.properties) provide the EJBs with all the cryptographic parameters they need to perform the signing and verification.
|
