Detailed Architecture

The present section further details the interactions between the components introduced in the architecture overview. Here you will find an in-depth description of the software components developed by Kryptiva and a summary of the protocols that connect them together; all of which are subject to Kryptiva's patents. For a description of the underlying cryptographic mechanisms, see the cryptographic protocol section.

To start, let's take a look at a detailed view of the interactions between the Kryptiva components:

This is a simplified view, and a lot of network components have been omitted in order to focus on the most important ones. Of the missing components, notice that the mail servers have been omitted from this figure. As explained in previous sections, the mail servers have no bearing on the interactions of the Kryptiva components since all Kryptiva-packaged email always follows its normal route using the existing mail servers. The following explanation would therefore gain very little by covering the mail servers.

That being said, let's dig deeper in the Kryptiva architecture to see what happens on the user station, the local Kryptiva Packaging Server (KPS) and the Kryptiva Online Services (KOS).

Kryptiva Software on the User Station

During the plugin installation on a user's system, two components are installed: the Kryptiva Packaging Plugin (KPP) and the Kryptiva Mail Operator (KMO). These two components are complementary to one-another. While the KPP, by definition, plugs into the user's existing email application to provide the user with the appropriate interface to Kryptiva's services, and is therefore very specific to the email application, KMO is a standalone application which is entirely independent from the user's email client application.

In essence, KMO provides all KPP instances (i.e. different Kryptiva plugins for different email clients) with a standard interface to the Kryptiva services through the KMO-Plugin Pipe Protocol (K3P). There are three main advantages to this design.

First, each email client application has its own peculiar way of providing a plugin interface. Supporting multiple mail clients would in reality require reimplementing the Kryptiva Network Protocol (KNP) for each one and would require having to update all mail clients for every modification of the KNP. By splitting the implementation of the KNP from the mail client, much work can be done in KMO without breaking the K3P. In other words, creating and maintaining plugins for a variety of email client applications is greatly simplified.

Second, in addition to providing awkward plugin interfaces, email client applications are often extremely limited in their ability to providing plugins with consistent data about stored emails and appropriate storage means for tagging pertinent information onto stored emails. Specifically, our experience has been that even the most reputable email client applications are simply incapable of attributing a permanent and unique identifier to every stored email. Either such identifiers do not exist or they are subject to changing and are, therefore, not permanent. And since such identification is essential for such things as authentication and encryption, a separate standardized storage capability must be provided for storing information in order to allow, amongst other things, unique identification of stored emails. This is the purpose of the KMO-DB shown above.

Third, by splitting the storing of decryption information separately from the conventional email store, as is done by KMO in KMO-DB, it is possible to isolate the reading of encrypted email from its storage. In other words, this allows user control of whether his system administrator can easily read his email simply by having access to the mail servers.

At application startup, the KPP launches one KMO instance and passes it all user requests using the K3P. When required, KMO establishes an SSL connection with either the KPS or the KOS to process the user request and thereafter returns the result to the KPP using the K3P.

The Kryptiva Packaging Server (KPS)

The KPS is built as a customized Linux distribution for installation on any standard server system for servicing local Kryptiva users. The KPS is provided to our corporate customers as part of the service signup and, once installed on the customer's hardware, is meant to be operated as a local appliance. Its only functionality is to respond to local requests by Kryptiva users. At no point does it "phone home" or establish any connections outside the corporate firewall. Its only outgoing connections are to the existing LDAP server if it is configured to use it in order to authenticate users.

From an administrative point of view, the KPS does not require any servicing. While it does provide a configuration interface, it is meant for initial setup and occasional reconfiguration. Since the KPS is stateless, it does not contain any data that needs to be backed up, save possibly for its configuration files. While the KPS stores two private keys, one for signing outgoing emails and one for decrypting incoming emails, neither needs to be backed up. Basically, these keys are not accessible to the system administrators and do not need to be made available since, as is explained in the technology rationale section, they are meant to be disposable.

When receiving packaging requests, the KPS first checks whether the requesting user has access to its services, typically using LDAP. If so, it then checks whether the content to be packaged is either spam or contains viruses. If it is determined that the content is spam or that it contains viruses, then packaging is refused. If all goes well, on the other hand, then the requested packaging is applied and the KPS returns to the KMO on the user station a Kryptiva Signature Packet (KSP) and, in the case of encryption and PoD, a packaged email body to be substituted to the original email body by the KPP.

Mail packaged by a KPS typically has a body starting with:

----- KRYPTIVA PACKAGED MESSAGE -----
PACKAGING TYPE: SIGNED

      ...

The body then follows in clear text, in the case of signed-only emails, or as an encrypted payload, in the case of encryption or PoD. In addition to the content or payload, the body also contains a notice to the effect that the email claims to have been packaged by Kryptiva and that a free plugin is available to the recipient from Kryptiva's website in case one hasn't already been installed. Much like Adobe's ® Acrobat or its Flash Player, the plugin's installation is a one-time operation. Once installed, all Kryptiva-packaged emails received are automatically processed by the plugin.

Finally, all Kryptiva-packaged emails end with a KSP:

----- KRYPTIVA SIGNATURE START -----
AvWVqAAAAAEAAAABAAAAAAAATiACAQAAAACLAQAAAAEAAAABAuVk5ir9LJdzxOuYrym8DQ8Z
s4JMA1OBxmO3bfaKAD2OZXjx9d5GpfPaBMk80UTnQ00Apo7BF/5TupmRCEG/Bsgbed88ZEjq
58T4BCi1TNVpKhfXB8Ob+Pc82mMYUDfd86sy4iUkWHtkESBOAAAAAAAA/UdPRWhQBABgAAAA
AAAAAAAAAIID/0F7Ux20p385He5og8gi/Wa3Cy1A5co51dArr1r1l8TXZ/yaX0XAXLgsSO3r
7uxJguMR59ko45YWTQ9t2jfZoDljcP8PbIP3Wzi6gidlVa+1QnnbVmzTvgx9hL9d4ISumBgQ
vdhq60zHvoiYD4DgUwWP7quW5XeNyQwBUnd6sj4d
----- KRYPTIVA SIGNATURE END -----

In itself, the presence of a signature such as this one or one similar to it does not guarantee that the packaging is indeed genuine. Only by having the KPP installed can a recipient verify the email's true origin and process PoD and/or encryption.

As is discussed in the cryptographic protocol section, the KSP contains a number of fields which are used by different components of the system in various situations.

The Kryptiva Online Services (KOS)

The KOS is actually an aggregation of five different services which are contacted by members and/or non-members, depending on the service. All services are publicly-accessible on the Internet and are directly contacted by KMO as needed using the KNP.

Identity-Key Server (IKS)
The IKS is used by both members and non-members. Its main purpose is to provide KMO with information about the Member ID (MID) found in the KSP. This includes the corresponding organization's name and the public key matching the private key used on the organization's KPS for signing outgoing emails. Using the public key returned by the IKS, KMO can determine whether the KSP is valid and provide the result of that verification along with the organization's name to the KPP for displaying to the user.

Encryption-Key Server (EKS)
The EKS is used by members to obtain the public key used by their recipients for encryption. Typically this matches the encryption private key stored on a recipient's organization's KPS. The EKS is used by KMO at packaging time to provide the KPS with the public keys of the recipients. If no key is found for a recipient on the EKS, then KMO informs the KPP that it must ask the sender for a password to encrypt the email to that recipient.

Online Unpacking Server (OUS)
The OUS is used by both members and non-members. In the case of members it is used to process PoD and in the case of non-members it is used to process both PoD and encryption. In all those cases, KMO must contact the OUS in order to be able to decrypt a newly received email and make it available to the KPP. Without doing so, KMO has no means to decrypt the email. The OUS' operation is further detailed in the cryptographic protocol section.

Online Token Server (OTS)
The OTS is used by members to obtain One-Time Use Tokens (OTUTs) for providing to non-member recipients so that they can respond securely to an encrypted email. To obtain an OTUT, KMO first contacts the local KPS which provides it with an OTUT ticket. KMO then contacts the OTS providing it with the ticket and obtaining a usable OTUT. The OTUT is then encrypted with the email and sent to the recipient. Upon proper decryption on the recipient side, an OTUT is provided to the recipient's KMO and stored in the KMO-DB for use in a future reply to the sender.

Online Packaging Server (OPS)
The OPS is used by non-member recipients to securely reply to members who have provided them with an OTUT in an earlier sent encrypted email. Using the OTUT, the non-member logs into the OPS and packages the reply. This is similar to what a member could do using a local KPS, except that the non-member can only request encryption, not PoD, and can only respond to the original sender. Once packaged, the email is returned to the non-member for replying to the original sender using the existing mail servers; the packaged reply is never stored by Kryptiva, except in RAM during its packaging.