The nameplate SpyProof! was originally used for an encryption product that would, using the AES cryptographic algorithm, create a virtual encrypted storage drive on your Windows PC and make it available in the File Explorer desktop. This allowed your drive to be seamless accessible not only from Explorer but also in any app that used the Explorer based file open and save dialogs, so almost all of them. In terms of ease of use for data security conscience people it was a great product. It was however given a back seat to another product in the portfolio called SecretAgent which has a longer legacy and thus on shareholder bottom lines showed more revenue. Unlike SpyProof!, SecretAgent took the opposite of transparent, seamless integration opting instead for multiple steps in both the protection and access steps when it came to secure data.

This essentially left SpyProof! to rot away as corporate resources were allocated to the product in the portfolio that had a more reliable stream of income. It was basically from a place of pure anger that the vastly superior architecture was being abandoned that caused an ambitious personal undertaking to revamp and upgrade the technology that from a user experience standpoint would, well, not suck. Thanks to Microsoft closing a loophole in trusted device drivers the file filter device driver received the Microsoft Hardware Compatibility certificate allowing it to be deployed and now all the experience improvements that were made in afterhours can be listed here.

The most important security consideration when implementing a system where cryptography is a security mechanism is preventing the exposure of the encryption keys. In this solution data encryption keys (symmetric) are protected with pubic (asymmetric) keys. The application does not perform any of the public key operations opting to instead use a private key security device through the Public Key Cryptography Standard number 11 API.

If this description already is taking a deep dive the solution to simply the complexity of PKI is to implement a profile concept as profiles are already widely used across apps and people have developed a familiarity. The profiles implemented here simply create a persistent link to the security device along with the preferred public key, in X.509 Certificate format.

Profile management is performing considerable amounts of overhead off-loading PKI management from the person creating or accessing data. As expected there would be a defect or required optimization discovered during field test. The Keys to the Kingdom update addresses deficiencies to all developers to continue to build data protection into the next up and coming features on the roadmap.