Cryptographic Protocol

Kryptiva's Email Integrity Platform relies heavily on cryptography. Like most other cryptographic systems, there are two parts to Kryptiva's architecture: the cryptographic protocol and the cryptographic algorithms. With regards to the algorithms, we rely on widely-known algorithms such as RSA, SHA-1 and AES. What makes Kryptiva's Platform unique is the patented cryptographic protocol explained below. Note that the following discussion assumes that you understand the operation of Kryptiva's Platform as explained in the features summary, the architecture overview and the detailed architecture sections, and have a solid understanding of cryptography.

Inside the KSP

Before digging right into the cryptographic protocol, we must first provide a little bit more information regarding the basic unit of operation of all Kryptiva components: the base64-encoded KSP generated by the interaction of KMO with the local KPS and the KOS.

The KSP is made up of various meta-data, such as version numbers and magic numbers, and individual subpackets. There are a variety of subpackets and a given KSP may include only a few. Example subpackets include: subpackets consisting of the hashed value of one of the email's fields, such as the "from" hash or the text body hash, subpackets consisting of encrypted symmetric keys and encrypted hashed passwords, and subpackets providing information on the packaging type, such as whether a PoD is required and whether the recipient has been granted an OTUT.

When the KSP is built, subpackets are added to it by the KPS until all of the options selected by the user have been accounted for. As part of this process, the KPS generates a MID-specific unique Kryptiva Serial Number (KSN) and includes it as part of the KSP. Once completed, the KPS signs the KSP in its entirety and attaches the signature to the KSP's tail before returning it to KMO. Thereafter, any component of the Kryptiva architecture that must process a KSP will first check that its signature is valid. If the KSP signature isn't valid, no Kryptiva component will further process it. Note that since each email field has a separate corresponding hash subpacket, Kryptiva components can check for the validity of each email field separately so long as the signature of the entire KSP is valid.

The explanations below will further describe how the KSP is used at every step of the email's processing to obtain the desired functionality.

The Keys

Kryptiva's cryptographic protocol relies on the mixing of a number of different keys and algorithms. For example, we may use both symmetric and public key algorithms for the same transaction and may also use different key pairs for different transactions between the same parties.

The basic principles of our protocol are that:
1. Each member organization has two key pairs: one for authentication and one for encryption.
2. The authentication key pair is generated by Kryptiva and attributed at signup.
3. The encryption key pair is generated by the member organization as part of the KPS installation; Kryptiva being provided with an encryption public key signed using the previously-attributed authentication private key.

To simplify further explanations, we represent each key in the system using four letters. In the case of keys used with public key algorithms, each letter has a separate meaning. The first letter indicates the party to which the key belongs: S for sender and R for recipient. The second letter indicates which of the party's key pairs this key belongs to: I for authentication (a.k.a. identification) and E for encryption. Finally, the last two letters indicate which type of key this is: PK for public key and SK for private key (a.k.a. secret key.) Hence, we have the following lexicon:
       RIPK: Recipient Identity Public Key
       RISK: Recipient Identity Secret Key
       REPK: Recipient Encryption Public Key
       RESK: Recipient Encryption Secret Key
       SIPK: Sender Identity Public Key
       SISK: Sender Identity Secret Key
       SEPK: Sender Encryption Public Key
       SESK: Sender Encryption Secret Key
All symmetric algorithm keys are represented as SYMK.

Currently, all authentication keys are 1024 bit RSA, all encryption keys are 1024 bit RSA and all symmetric keys are 128 bit AES. These key lengths could easily be changed in the future if need be.

The following figure illustrates where a copy of each key is located:

Note that while the KOS does possess a copy of the private keys used for authentication, these keys are never made available to the outside world. Instead, they are used internally for processing such things as sender-requested PoDs and password-encrypted emails sent to non-member recipients. The system could have been configured differently, say with additional key pairs for example, but in real-world conditions this configuration works well.

Following the KSP Around

The best way to explain the protocol's behavior is to follow the KSP from the point it gets created to the point where the recipient "unpacks" the packaged email. In all packaging scenarios, the sender's KMO transmits all of the individual email fields ("from", "to", "cc", "subject", "text body", "html body" and attachments) to the KPS along with the user's packaging options.

Worthy of special emphasis, notice that, except for encrypted replies of non-member recipients having been granted an OTUT by a member recipient, Kryptiva's online servers never need to have access to the email contents. In fact, once packaged, the email follows the same path a conventional insecure email would have traveled. Only the KSP is exchanged in between the KMO and the various Kryptiva components for handling decryption and PoD.

Authentication
In the case of authentication, the KPS instantiates a KSP and proceeds to fill it using subpackets containing the cryptographic hashes of each email field. Currently, the KPS uses SHA-1 for this purpose, but SHA-256 could also be used. Once all the hashes are in the KSP, the KPS uses the SISK to RSA-sign the entire KSP. The signature is then added to the KSP, and the latter is sent to KMO which provides it to the KPP. The KPP then attaches it to the outgoing email for delivery to recipients using the existing mail servers.

At reception, the recipient's KMO retrieves the MID from the KSP and requests the corresponding member information, including the SIPK, from the IKS. KMO then uses the SIPK to verify the KSP's signature. If the signature is valid, KMO then proceeds to verify whether the hashes of the various email fields are valid. This allows it to inform the KPP whether the email contains a valid KSP and what the status of each email field is (ex.: the "from" has changed, but the "to", "cc" and text body are intact.)

While this will not be discussed specifically below, all Kryptiva packaging options imply authentication. Any KMO packaging request to the KPS implies a request for authentication and any receiving KMO will first validate authentication prior to conducting any other operation. If a received email claiming to having been packaged by Kryptiva fails to authenticate, the receiving KMO will mark it as containing an invalid signature in KMO-DB.

Tracking
The basic premise of Kryptiva's implementation of tracking is that the recipient must be forced to provide the sender with PoD prior to being able to read the email's content. To this end, on receiving a PoD packaging request, the KPS generates a random SYMK and AES-encrypts the email's body and attachments with that SYMK. The SYMK is then itself RSA-encrypted with the SIPK. The encrypted SYMK is then added to the KSP as a subpacket. Also, the encrypted email body and attachments are joined together to form an encrypted payload which is substituted to the original email body. The KSP and the new email body are then returned to KMO which forwards them to the KPP for delivery to the recipient using the existing mail servers.

Upon receiving the PoD'ed mail, the recipient is given the option of ack'ing the PoD or not reading the email. If the user accepts to ack the PoD, the payload and KSP are handed to KMO. As a consequence of what was explained earlier, KMO now needs to be able to retrieve the original SYMK in order to decrypt the payload. Since SYMK was encrypted with SIPK, the only way to decrypt it is to use the SISK. To this end, KMO contacts the OUS, provides it the KSP and requests it to decrypt the SYMK. Since the OUS is part of the KOS and that, as mentioned earlier, a copy of the SISK is available to the KOS, the SYMK is decrypted and handed back to the recipient's KMO and a PoD is sent to the original sender. The recipient's KMO can then decrypt the payload and hand it over to the KPP which makes it available to the user. In the process, the SYMK is stored in the KMO-DB for future requests by the user to read the encrypted email.

Notice that although KMO needed to use the OUS to get the decrypted SYMK, the payload was never seen by any component of the online services, either in encrypted form or in the clear, at any point in the transfer. As mentioned earlier, the payload followed the same route it would have had the Kryptiva services not been used.

Encryption to a Member
Sending an encrypted email to a member recipient is a matter of finding his REPK. This is done by KMO at send time by contacting the EKS. Once all recipients' keys have been found by KMO, they are sent with the email to the KPS. The latter first checks that the keys are valid and then proceeds to effect a similar process as in the case of the PoD. First, a random SYMK is generated and is used to AES-encrypt both the email body and attachments; which are packaged as a new body as in the case of the PoD. The SYMK is then RSA-encrypted once for each REPK provided by KMO; each encrypted SYMK being added to the KSP as a separate subpacket. Note that each encrypted SYMK subpacket also includes the encrypted email addresses of the recipients who are allowed to read this email. If the packaging request also includes a PoD then the SYMK is encrypted twice, first with the SIPK and the second time with the REPK. Again, as in the PoD case, the completed KSP and payload are returned to KMO for delivery to the recipients using the existing mail servers.

When receiving such an encrypted email, the recipient's KMO logs into the local KPS, provides it with the KSP and requests that it return the decrypted SYMK. The KPS then checks whether the requesting account's user's email address is part of those part of the designated subpacket. If so, the KPS uses the RESK to decrypt the SYMK and provide it to the requester. If a PoD request is attached to the KSP, then the recipient's KMO also needs to contact the OUS to further decrypt the SYMK as explained in the previous section. Having obtained the decrypted SYMK, KMO can then decrypt the payload and provide the KPP with the email's content and attachments. Here too, the SYMK is stored in the KMO-DB for future use.

Again, notice that the payload was never seen by any component of the online services.

Encryption to a Non-Member
The process for packaging an email to a non-member is similar to that for packaging an email to a member except that instead of providing the KPS with the recipients' keys, KMO provides the KPS with a password for each non-member recipient. The hash of each password is encrypted with the SIPK and added as a subpacket to the KSP. The rest of the process is identical to the case of encryption to a member, including if a PoD was requested.

Upon receiving the encrypted email, the recipient is prompted for providing the password as he knows it. This password is then provided by the KPP to the KMO. In turn, the KMO contacts the OUS and provides it with both the KSP and the password provided by the user. If the password hash matches one of those in the KSP, the OUS returns the decrypted SYMK and the KMO is then able to decrypt the payload and provide it to the KPP. If the KSP included a PoD request then the OUS would take care of that as part of the process. Again, the SYMK is stored in the KMO-DB for future use.

Once more, notice that the payload was never seen by any component of the online services.

OTUTs and Encrypted Non-Member Replies
In the case where a member sender wants to allow a non-member recipient to respond securely to his email, the sender's KMO first contacts the KPS to request an OTUT ticket. This ticket is provided by KMO to the OTS in order to obtain a valid OTUT. This OTUT is then given to the KPS as part of the encryption packaging request to the non-member recipient.

At the receiver's end, upon successful decryption of the SYMK by the OUS, the recipient's KMO gets access to the OTUT which is then stored in the KMO-DB for the recipient to use for his reply. When the recipient attempts to reply, the recipient's KMO uses the stored OTUT to log into the OPS and package a reply to the sender. By doing so, the OTUT is consumed and cannot be reused.

This is the only case where the payload is seen by a component of the online services. As mentioned in the detailed architecture section, the packaged reply in this case is never stored by Kryptiva, except in RAM during its packaging.