The CryptoMail SeXMAP (Secure Xml Messaging Access Protocol) Specification

Introduction

The intention of this document is to specify in full detail, a way to securely implement the XMAP protocol mostly, but not entirely over insecure HTTP. It also is intended to blueprint a methodology to perform end-to-end message encryption and provide a basic user session tracking and user authentication mechanism.

It is worthy to note that not all agents that are HTTP aware, are equally capable of performing HTTPS/SSL. A prime example of this is the current implementation of the JAVA VM. Due to either to licensing, export restrictions, or the whims of the powers that be at Sun, HTTPS/SSL was not included in the JAVA VM for the JDK 1.1. Thus, java applications/agents that require transfering data payloads securely via an insecure protocol have the onus of security placed on them. One possible solution entails going elsewhere for the functionality by using a third party library which supports HTTPS/SSL. An example of such support would be using ficticious vendor "SecURL" which sells / licences its "Java Secure URLConnection Object" which conforms to the HTTPS/SSL protocol and the URLConnection JAVA Interface. Another solution would be for the application to employ basic cryptographic libraries and principles which essentially encapsulate / mimic what HTTPS/SSL does. The CryptoMail methodology of performing secure XMAP message transfers is the latter methodology which does not require 3rd party HTTPS/SSL vendors, but instead some knowlege of Asymmetric public key algorithms and Symmetric private key algorithms.

Who are you, and should you be here?

XMAP purposefully omits the notion of authentication. There are many ways to perform authentication over an insecure channel, however the following represents one possible way to perform authentication and maintain a secure channel over HTTP to perform XMAP requests.

Secure Session Initialization

1. The user via HTTP is served a login form that only has the user's login name
2. The form is submitted via HTTPS and:
3. The user is looked up in the user list. If the user does not exist, an error html page is shown and the user goes back to 1
4. The server generates and records an ElGamal Public/Private Key Pair
5. The server generates and records a session token consisting of 16 bytes within the alpha-numeric domain
6. The server generates and records a session token representing a "Session Cloak" consisting of 16 bytes within the alpha-numeric domain
7. The server generates and records a random blowfish key hereby known as the "cloak key", consisting of 16 bytes (128 bit)
8. The server constructs a page consisting of the CryptoMail applet and passes The ElGamal public key, the session token, the session cloak, and the blowfish cloak key are passed in as parameters to the applet, and the Applet page in entirety is served to the client via HTTPS. This is done to ensure (abate the chances of :)) no one can pick up any of the applet parameters.
9. The applet reads in all the parameters it was passed.
10. The applet then constructs a random 16 byte (128 bit) blowfish key and encrypts it via the ElGamal public key that it was given by the server
11. The applet then constructs a message consisting of the publicly encrypted session blowfish key. The message has the following format: <BLOWFISH EncryptedKeyInHex="EncryptedKeyInHex"/>.
12. The applet then takes the cloak key, and encrypts the session cloak via CBC blowfish
13. The session token, and the CBC Blowfish encrypted session cloak become part of the HTTP header information.
14. The server looks up the session token from it's store
15. If the server cannot find the session, it is an error: abort
16. The server looks up the session cloak and the cloak key from the session token it was passed from the client
17. The server decrypts via CBC Blowfish the encrypted session cloak that it was passed from the client
18. The server then compares the known session cloak to the decrypted session cloak. If they are not the same, error : abort
19. The server then looks up the private key based on the session token it was passed
20. The server then decrypts the publicly encrypted blowfish key with the recorded private key
21. The server then records the privately decrypted blowfish key. This key will now be known as the session key.
22. The server then uses the session key to CBC Blowfish encrypt the following message: <IKISSYOU/>
23. The client then reads and decrypts the message passed back by the server and ensures that it says <IKISSYOU/>

Logging in to the CryptoMail Server

A session is established using steps 1-23 of Secure Session Initialization.

1. The client requests a passphrase from the user
2. The client uses the SHA-1 algorithm to formulate a hash on the passphrase
3. One half the hash value is used to construct a LOGIN message with the following format: <LOGIN HalfTheHashOfThePassphrase="HalfTheHashOfThePassphrase"/>
4. The client performs step 12 and 13 of the Secure Session Initialization routine.
5. The "LOGIN" message is encrypted via CBC Blowfish using the negotiated session key in the Secure Session Initialization Session
6. The client sends the message to the server
7. If the server responds with <LOGIN PublicKey="PublicKey" EncryptedPrivateKey="EncryptedPrivateKey" EncryptedHashOfPrivateKey="EncryptedHashOfPrivateKey"/> the user is "logged in", else the user is not logged in and is passed <ISLAPYOU/>
8. If the client is not logged in, it is forced to go through the Secure Session Initialization routine again. Error abort.
9. The client then decrypts the private key with the full passphrase
10. The client then decrypts the hash of the private key with the full passphrase
11. The client then performs a SHA-1 hash on the private key and compares the hash to the decrypted hash
12. If the client determines that the decrypted hash and the live hash of the private key are not the same, error abort

Creating a CryptoMail Account

A session is established using steps 1-23 of Secure Session Initialization.

1. The client creates a 1024 bit ElGamal Public/Private Key Pair
2. The client chooses a passphrase
3. The client encrypts the private key with a CBC Blowfish using the passphrase as the key
4. The client formulates the hash of the passphrase using SHA-1 and saves half of it.
5. The client formulates a hash of the private key using the SHA-1 algorithm and encrypts it via CBC Blowfish, again using the passphrase as the key
6. The client then formulates a "NEWACCOUNT" message in the following format: <NEWACCOUNT PublicKey="PublicKey" EncryptedPrivateKey="EncryptedPrivateKey" HalfTheHashOfThePassphrase="HalfTheHashOfThePassphrase" EncryptedHashOfPrivateKey="EncryptedHashOfPrivateKey"/>
7. The client then performs steps 12 and 13 of the Secure Session Initialization routine
8. The "NEWACCOUNT" message is encrypted via CBC Blowfish using the negotiated session key in the Secure Session Initialization Session
9. The server sends back either an affirmative response <IKISSYOU/> or a negative response <ISLAPYOU/>

Changing One's Passphrase to a CryptoMail Account

A session is established using steps 1-23 of Secure Session Initialization.

The client logs in to the cryptomail server and decrypts the encrypted private key with the passphrase.

1. The client chooses a passphrase
2. The client encrypts the private key with a CBC Blowfish using the passphrase as the key
3. The client formulates the hash of the passphrase using SHA-1 and saves half of it.
4. The client formulates a hash of the private key using the SHA-1 algorithm and encrypts it via CBC Blowfish, again using the passphrase as the key
5. The client then formulates a "CHANGEPASSPHRASE" message in the following format: <CHANGEPASSPHRASE EncryptedPrivateKey="EncryptedPrivateKey" HalfTheHashOfThePassphrase="HalfTheHashOfThePassphrase" EncryptedHashOfPrivateKey="EncryptedHashOfPrivateKey"/>
6. The client then performs steps 12 and 13 of the Secure Session Initialization routine
7. The "CHANGEPASSPHRASE" message is encrypted via CBC Blowfish using the negotiated session key in the Secure Session Initialization Session
8. The server sends back either an affirmative response <IKISSYOU/> or a negative response <ISLAPYOU/>

End-to-End Message Encryption

1. The client constructs an email message using the CryptoMail applet
2. For Each Recipient R do:
3. The client then performs steps 12 and 13 of the Secure Session Initialization routine
4. Get R's PublicKey from the server by encrypting and sending a "PUBLICKEY" request.
5. If R's PublicKey cannot be negotiated, the message will not be encrypted to anyone error abort
6. End For
7. For Each Recipient R do:
8. The client formulates a random blowfish key consisting of 16 bytes (now known as the message session key)
9. The client encrypts the message session key with R's PublicKey
10. The client encrypts the message body with the message session key
11. The client puts the message session key in the message header of the message using MIME encapsulation. The tag is called "X-CryptoMailSessionKey"
12. The client sends the server an encrypted "SENDMAIL" request.
13. End For

SeXMAP Data Dictionary And Request/Response Table

Legalese

All trademarks and logos are used for identification purposes only and are owned by their respective companies. CryptoMail.org does not guarantee any satisfaction and does not provide any warranties about this document (The CryptoMail SeXMAP Specification). This document is posted as public domain information. If you decide to quote any information from this document, you must attribute and state the source of this document. Copyright © 2000 CryptoMail, Inc. All rights reserved.

Joshua Teitelbaum (joshuat@cryptomail.org) wrote the first version of this document in 2000. Mail me if you have any questions about this document.

The CryptoMail SeXMAP Specification, Version 0.90, 4/22/2000