Security Console - 7

Last updated on: 1/6/2016 2:57 PM 
Created on: 11/2/2016 2:22 PM 

Larry Page of Google is quotes as telling his employees "This is the path we're headed down - a single unified, 'beautiful' product across everything. If you don't get that, then you should probably work somewhere else." The System Core framework provides a platform in which certificate enabled security applications can be easily created with a consistent user interface. The framework blends the ability to select and manage access control lists, with local contacts and those dynamically available directory servers, enforce organizational configurations. Public key cryptosystems are automated behind the scenes of a native platform interface for a more intuitive experience without compromising the power of the Public Key Infrastructure.

Developer's Overview

As an employee of Information Security Corporation for over 16 years I have seen many design challenges in developing data protection products. Each iteration progressed through the evolution from Public Key Cryptography to the use of X.509 Certificates and the many technologies that emerged to handle the administration of certificates.

The software products, whether off the shelf products or custom applications developed by the consulting side of the business, needed to stay current on new standards; revocation lists, certificate authorities, etc. For many years this meant developing a new feature in one product and then working with the other developers to make sure the same implementation was functioning properly in other applications.

In the early days there were only a few applications and platforms that were supported, however this was also back when the primary means of sending data from one machine to another was through the use of floppy disks. As new ports to platforms were required, most of the work had to be recreated. This became especially true when mobile devices running Windows CE came into play.

When the flag ship product reached version 6, a number of issues began to be resolved. Qt was selected as the toolkit for its ease of portability, addressing the issue of running the same code base on different platforms. However during development it became a requirement to also build another of our products into the new version. This required a split of functionality that would create an additional application quickly dubbed "Security Console". For consistency and ease of version identification, all the products, including the new framework, were given the version number of 6.

Even with these enhancements the software didn't evolve to embrace the emerging network and constant connectivity. The next generation of all the company products were to include features that would be network aware and support an administrator roll out. In order to to this, a complete rewrite of Security Console would be needed to add the additional functionality required to accommodate optimized code use, isolation of features for faster development times for enhancements, better separation of responsibilities for ease of code maintenance and faster development of new products by fully taking advantage of code reuse.

To accompany this, Security Consoles name was shifted to Security Core for version 7 and would be the first ever product in company history to be designed bottom up. In the past, the top down approach that remained common, led to code that was desktop platform portable. With the vision of supported tablets and mobile platforms like Android, a solid framework was required with features such as user interfaces being modular and easily targeted. The PKI features that made the original SC became an area of the core known as the PKI Experience. The core is originally being embedded into a system tray app so it can run in the workstations background, however it can also be easily included into a service to run as a server process as needs arise.

All the features of the core are customized through the core's many interfaces. Products that run on top of the core are then implemented through the applet interfaces allowing the developer to focus on the application specific functionality. Both the PKI functions and the user interface interactions are handled by the core and are intentionally hidden from the application developer. This is done for the reasons of portability to allow the developers of the core to easily handle the differences in layout and implementation between platforms such as Windows and Android, while not risking the introduction of issues in application logic.

Developer's Historical Persepctive Why A Platform Standards The User Experience

Interfacing the API

The Security Console Platform implements the standards of a Public Key Cryptosystem. Applets that are using public key cryptography to provide data security need access to these features. Some features require network communication, some require policy enforcement, some handle private key access and there are some that manage the user interaction with these components.

To handle all the management that is involved, there are Framework Managers. The application creates an instance of each manager and in turn the manager exposes several public methods that an applet can invoke to obtain the needed information. The managers are able to hide the nitty-gritty details of the infrastructure from the applets. The applet just needs to obtain a handle to the proper manager and then access the public method needed.

This separation allows the platform developers to improve or enhance the infrastructure features without affecting the applets and applet developers can improve the user experience without worrying about back end details. The importance here is that being a software house for a niche market, off the shelf products never meet anyone's needs. Being a small company we have been able to adjust and meet changing standards in PKI. This, has become known as our "PKI Experience." The framework and it's managers provide this experience to our eco-system. It also allows the framework to take the form of what ever we need it to be, a system tray for client machines or a service for back ground processing.

While the Framework provides this flexibility, it does not provide any user interface functionality. A separate layer of UI is created on top of the framework. On top of this layer sits the Developer specific Applets. To access the framework, developers must implement one or more of the framework's interfaces. The first interface that must be implement is the ISCApplet. This also forces all user interactions to be performed within an applet. For example, while the framework handles the Identity and PKCS#11 device management functionality, the user interactions to manage Identities is handled in a specific applet. By forcing all user interactions to be handled using these interfaces, the framework developers keep their flexibility to add enhancements or even modify visual components per platform as necessary.

The core of every product, service, utility or tool that is built using the framework must be a framework applet. This requirement forces the consistency of having all user interactions be identical while separating the developer specific functionality from the framework functionality. There are several interfaces into system core, which are all identified as having their classes begin with ISC. Each interface handles a specific component of the end user interaction. While ISCApplet is required, additional interfaces are only required if the applet requires that specific level of functionality. The framework makes the determination at runtime which additional interfaces to ISCApplet are used and registers the applet with the appropriate framework managers. By implementing the API using the framework manager methods and through interfaces the areas of public key management, network overhead and user interface rolls are separated out to be worked on by their associated experts thus yielding an experience of high quality, reduced development times and over all better project management.

ISCApplet ISCTaskListExtension ISCConfigPanelExtension ISCErrorReporterExtension ISCLogConnector/ISCLogEntry ISCCertificateStoreExtension ISCSystemTrayExtension ISCAppletWindowExtension ISCSecureObjectExtension

SAM Started It

The first version of the product that would become Security Console was released as SecretAgent 5.6 for Pocket PC.  In this application you would pick a file and if it was one of our archives it would be decrypted, if not it would be encrypted.  Since it was a minimal functionality port of our desktop client application this software contained many configuration steps and required a bunch of screen taps to complete the task.  To eliminate these steps a new paradigm was unveiled.

In this new automated approach, once you put data in the system it would stay secured in the system until you specifically remove it.  If you need to edit a file the system will allow you to do that and take the steps needed to keep the data secured when you were done.  Naturally this application needs to go beyond the encryption and decryption process.  Tis is public key cryptography requiring all the encryption steps to have knowledge of users keys.  Standardization of X.509 certificates for the public keys become central to the application.  Growing from SecretAgent 5's "key management utility" which later was rebranded as Certificate Explorer (Microsoft started sticking the word explorer after word they could; Windows, Internet, Ford, Jungle, etc... ) became the central place for contacts. For portability back to the desktop a framework was created. The revamped product included classes to handle the certificate management and a group of classes to handle the policy settings. Users were given the flexibility to configurable settings and provide for easy synchronization.

This product is currently out of production as WinCE has long been abandoned for Android. The design decisions put into mobile platform however remain and are part of the core philosophy ported back to the desktop applications in the new framework branded Security Console.

SecretAgent Mobile (SAM) User Interface Size Constraints and Considerations Automatic Data Protection Certificate (Contact) Management Certifications


Developer's Historical Persepctive Why A Platform Standards The User Experience


ISCApplet ISCTaskListExtension ISCConfigPanelExtension ISCErrorReporterExtension ISCLogConnector/ISCLogEntry ISCCertificateStoreExtension ISCSystemTrayExtension ISCAppletWindowExtension ISCSecureObjectExtension

Applet Building Steps

Step 1: Create The Applet Step 2: Adding Action Items Step 3: Adding Configuration Panels Step 4: Adding Custom Error Text Step 5: Startup/Shutdown Step 6: Adding Main Window Support Step 7: Adding Obejct Window Support