SecureEmailSystem

Enter a topic name to show or a new topic name to create; then press Enter

System Overview

This is a system to manage keys, public and private, for individuals wanting to use secure and private email. It works with all existing email systems that accept attachments, where the attachment is a ciphertext. All communication between the client and server is encrypted using TLS v1.2. Communication between servers is also TLS v1.2 encrypted.

The client is responsible for the creation of an attachment where the plaint text message has been converted to a ciphertext message readable only by the intended recipient. The ciphertext is signed so that the recipient can validate that it came from represented originator. The client sends the initial public key to the server. The client validates the public key on the server and performs automated repudiation when required. The client updates the server public key when a new key is generated and marks the prior current key as inactive. The client has a mechanism to mark the discontinuation of service for an individual. All communication with the server uses encrypted messages, in addition to the TLS v1.2, and those encrypted messages are signed for verification. The client is responsible for generation of one-time use symmetric keys, where every attachment has a unique key.

The server is responsible for acting as a directory for recipients by storing the public keys. Servers can be distributed with the key directory replicated between all participating servers. The client will have a list of all participating servers to ensure server availability. The multiplicity of servers raises reliability of the service, but it is also possible to deploy a server without redundancy, which would be used by a group wanting a higher degree of privacy.

The server would retain copies of all public keys for an individual but would have a status mechanism to manage current and past keys. It would also manage repudiation where an invalid key was inserted into the system through an invalid mechanism. It is necessary to retain old keys so that ciphertexts created with that key can be decoded even after the key has become inactive. The server is responsible for synchronization of all keys to all participating servers. The first server in a set of participating servers can blacklist any participating servers.

The server would only have the private key for itself and that private key would only be used for signing communications with other servers and clients. It would never be used in any of the user to user communication channels. Clients would only have access to their own private keys, never to the private keys of any other users or servers. Because of this isolation there is no way for interception except to compromise individual client instances.

System Licensing

Both the server and the client software will be open source, with those elements released by myself using using the Apache 2 license. Others may create implementations using other open source licenses without limitation in order to meet their requirements.

System Server

The server is a directory of public keys for participating email users and a directory of public keys for participating servers. The directory of email users is synchronized amongst all participating servers. The server verifies communication from a client via signed messages. The server verifies communications from other servers with signed messages. All intra-server communications are verified via signed messages.

The server has a web page that publishes a list of participating servers. The server has a web page that provides links to various client and server implementations.

System Client

The system client is responsible for key generation of the local user, local private key storage and access, public key distribution and verification to system server, key retrieval for intended recipients, creation of ciphertext for a recipients and decryption of received ciphertext to plaintext and verification of originator. The server verifies all communication with the clients through client signing of messages.

Private Key Storage

Private keys should be stored in the best security mechanism available for the host OS. In Windows this should be a Cryptographic Next Generation (CNG) Provider. In Apple this would be the keychain. For Linux or BSD it would be stored on a USB key using encfs or bindfs.

Implementation Details

All servers must implement a public set of properties appropriate for the version of server. All clients must implement a public set of properties appropriate for the version of client. These lists of properties and the version that originate from are included below.

There is a list of public APIs for both the client and server. These APIs must be implemented using OData.

Server Properties

This list may change until the release of v1.0

  1. Server Guid
  2. Server OS Type
  3. Server Public IP
  4. Server Creation UTC
  5. Server Web Home Page
  6. Client List Data
    1. Client Guid
    2. Client Creation UTC
    3. Client Email Address
    4. Client Public Key List
      1. Client Public Key Data
      2. Client Public Key Creation UTC
      3. Client Public Key State
      4. Client Update UTC
      5. Client Synchronization Status
  7. Server List Data
    1. Server Guid
    2. Server Creation UTC
    3. Server IP Address
    4. Server Public Key List
      1. Server Public Key Data
      2. Server Public Key Creation UTC
      3. Server Public Key State
      4. Server Update UTC
      5. Server Synchronization Status

Client Properties

This list may change until the release of v1.0

  1. Client OS Type
  2. Client Version
  3. Client List Data
    1. Client Guid
    2. Client Email Address
    3. Client Creation UTC
    4. Client Public Key List
      1. Client Public Key Data
      2. Client Public Key Creation UTC
      3. Client Public Key State
      4. Client Update UTC
      5. Client Synchronization Status
  4. Server Master Guid
  5. Server List
    1. Server Guid
    2. Server Creation UTC
    3. Server IP Address
    4. Server Web Home Page
    5. Server Public Key List
      1. Server Public Key Data
      2. Server Public Key Creation UTC
      3. Server Public Key State
      4. Server Update UTC

Server API

This list may change until the release of v1.0

  1. ValidateServerVersion
  2. RegisterNewServer
  3. RegisterNewClient
  4. UpdateClientData
  5. SyncServerList
  6. SyncClientList
  7. PutClientInfo

Client API

This list may change until the release of v1.0

  1. ValidateClientVersion
  2. SyncServerList

Message Encryption

Both the client and the server must implement the Message Encryption to the following standard:

  1. Get Plain text message - P
  2. Hash Plain text message using SHA512 - H(P)
  3. Create signature by encrypting hash value H(P) using originator's private key - S
  4. Append Signature create in step above to plain text P + S
  5. Create One-time use symmetric key - Ks
  6. Get verified Recipient's public encryption key - Krpub
  7. Encrypt the Plain text and Signature using the symmetric key to create the ciphertext
  8. Encrypt the one-time use symmetric key using the recipient's public encryption key
  9. Create the message by appending the ciphertext and the encrypted on-time symmetric key to the originator's public key certificate

Message Decryption

Both the client and server must implement the Message Decryption to the following standard:

  1. Receive encrypted message.
  2. Extract originator's public key certificate and verify
  3. Extract the encrypted one-time use symmetric key
  4. Decrypt the one-time use symmetric key using the recipient's private key
  5. Decrypt the ciphertext using the decrypted one-time use symmetric key to create the plain text and signature
  6. Decrypt the signature using the supplied originator's public key to create the hash value
  7. Hash the plain text using SHA512 to create the hash value
  8. Compare both hash values to validate the message

Attachment Format

The encrypted attachment is formated as an xml file with the following format

  1. doc
    1. OriginatorVerificationPublicKeyCertificate
    2. RecipientThumbprint
    3. cipherText
      1. PlainText
      2. Signature
    4. EncryptedSymmetricKey
      1. EncryptedAesKey
      2. EncryptedAesIV

Version: 29   Revised: 2015-01-29 09:04:31 Last Updated by: 2001:470:1d:80b:ec1a:c51e:9eb7:b2d8 Rename Show Links to Topic