Email Application

Introduction

Once the end-user owns a PrivateKey, he is able to use the different applications integrating ClassicSys.

What happens (to take just one example), when the end-user wants to make use an Email application with integrated ClassicSys ? Note : ClassicSys acts in a similar way for all other applications (banking, voting, games, ...).

Email is a good example because the cryptographic part of it is easy to develop and integrate in existing mail applications. Furthermore, demand is enormous (Internet, ...) and the investment required, limited.

For Email application, we only consider the cryptographic part of it. The other Email functionalities should be supplied by specialized software like MS-Mail, MS-Exchange, ... Our intention is not to limit the use of ClassicSys to one Email package but to encourage it's integration into all developments. Developing Email applications is one thing, developing cryptography tools another !

Distribution of national Email SessionKeys

Whenever Alice wants to send secure messages to Bob, she needs a dedicated SessionKey to cipher her messages. The TA only needs to send this information once, whatever the number of messages Alice will send to Bob.

But ...

• to decipher the messages received from Alice, Bob doesn't need a SessionKey. His PrivateKey is enough.
• if Bob wants to reply or to send a message to Alice, Bob doesn't need another dedicated SessionKey. The one from Alice to Bob is enough.

... for commercial reasons one may decide to require a new SessionKey from Bob to Alice.

Alice contacts the appropriate TA (i.e. the TA of her country) and gives it the ID-number of Bob, which is public.

In return, the TA sends the following encrypted information to Alice :

• the SessionKey from Alice to Bob allowing Alice to cipher messages to send to Bob
• the inverse SessionKey allowing Bob to decipher the messages coming from Alice.

The SessionKey from Alice to Bob is encrypted in such a way, that Alice is the only person able to decrypt this SessionKey (this encryption is done by Alice's TA, with the help of Alice's stamp, which has been used for the installation of her PrivateKey).

In the same way, the inverse SessionKey is encrypted in such a way, that Bob is the only person able to decrypt it (this encryption is done by Bob's TA, which in this case is the same as Alice's TA).

The only contact is from Alice to her TA. This gives her the inverse SessionKey which her Email sends automatically to Bob.

Note : Alice and Bob are not obliged to record the clear versions of their SessionKeys. With the encrypted data received from the TA they may, at any time, reconstruct the SessionKeys.

By doing this, the TA has sent, via unsecured channels, the necessary information to Alice and Bob (and only them) so that they may compute, every time they need it, the direct and inverse SessionKeys.

Click here for more details.

This expanation is illustrated by the following figure.

Distribution of international Email SessionKeys

The distribution of international SessionKeys follows the same principle as the distribution of national SessionKeys but in this case :

• instead of one TA, two TAs are involved : the one from Alice and the one from Bob.

To deliver the inverse SessionKey to Bob via unsecured channels, a contact between Alice's TA and Bob's TA is absolutely necessary : it is Bob's TA who ciphers the inverse SessionKey in such a way that only Bob may decipher his inverse SessionKey.

Click here for more details.

This expanation is illustrated by the following figure.

Alice sends a message to Bob

As the SessionKeys are never recorded by end-users, but are rebuilt every time messages are sent, first the SessionKey (K_ses) is reconstructed with the information received from the TA (see "more details", first block).

The message sent by Alice to Bob contains :

• the "message stamp" in clear (ID sender, ID receiver)
• date and time of encryption
• information given by the TA to be sent to Bob (third and fourth block, see "distribution of national and international SessionKeys") to allow him to reconstruct the inverse SessionKey (K^-1_ses), enabling him to decipher the message
• the message itself encrypted by Alice with the SessionKey
• a "message signature" obtained by hashing the content of the message.

Bob receives a message from Alice

Bob does never possess the inverse SessionKeys. He finds them in the messages sent to him. As mentioned above, the inverse SessionKeys are encrypted in such a way, that he is the only person able to decrypt them.

So, when receiving a message, Bob :

• checks the message integrity by hashing the received message and comparing it with the message signature
• reconstructs, by deciphering, the inverse SessionKey, K^-1_ses
• deciphers the message, sent to him, using the inverse SessionKey, K^-1_ses.

National Security Service (NSS)

National Security Services exist to defend our Communities and Democracies against dangers such as serious crime, terrorism, ...

Therefore all NSSs must be able to decipher every suspect message inside their country.

The NSS acts like a normal end-user towards the TA :

• the NSS has a public ID-number
• the NSS owns a PrivateKey
• the NSS owns SessionKey to the TA.

In addition, it owns a password given by the TA during installation allowing it to be recognized as an NSS.

The NSS contacts the appropriate TA and gives it the identification of the sender and the receiver of the suspect message.

In return, the TA gives the direct and inverse SessionKeys corresponding to the suspected message.

Click here for more details.

Note : the system described above is our view the world and van be adapted by adding other features (adding address blocks in messages, adding an access code to the hardware, ...).