logo
Secure Message (BETA) Back to Home Page



Secure Message is a 4 part program consisting of two server components and two client components. The main server component (sMsgSvc.exe) runs as a Service, and must be accessible from the WAN (Wide Area Network aka Internet) on a listening port of your choosing. The service has no visible components and operates with system privileges in Session 0. It comes with a small management program (sMsgCtrl.exe) to provide the necessary interface between the Service Manager (services.msc) and the service itself. There is a daily log file to record access and errors.

The server component can also be run as a Desktop application (sMsgS.exe) with a small window, which is how most users will operate in the beginning. Everything noted about the Service above also applies to the Desktop server component, as it is essentially the same program. The only noticeable difference is the location of the log files. The Desktop server component logs to a sub directory (folder) of the directory where it is located, whereas the service logs to "\Windows\System32\Logfiles\sMsg\".

sMsg is short for Secure Message, as all transmitted messages and attachments are fully encrypted using a 256 bit Elliptical Curve key. Each client must have a UserID, and a password is required to activate the Client program and connect to the server. The UserID/Password must also be registered with the server. When the Client connects to the server, it sends the UserID and a Public ECC (Elliptical Curve Cryptography) key. The server uses that Public key and it's own Private key to generate a "Shared Secret". The server then sends it's Public ECC key back to the Client. The Client uses it's own Private ECC key and the Public key from the server to generate the same "Shared Secret" as the server. The Client then Encrypts a hash of the password, and sends it back to the server. The server decrypts the password hash and verifies that it matches the UserID.

The Client part of the program consists of 2 programs, only one of which needs to have an activation link (Tray.exe). This portion connects with the server and performs all the network communication.

It also interfaces with the second part of the program (Msg.exe), which performs all the database functions. Msg.exe can be activated by clicking on Tray Icon, and it will display the data currently in the Inbox portion of the database.

"Msg.exe" has limited functionality without "Tray.exe" running and connected to the server. To obtain the current status, hover your mouse above the Icon. If not currently connected to the server, the Icon background will be red.

These programs were developed to get around some of the limitations of the existing email system. The current Email standards are ancient and difficult to work with. It does not easily support encryption or non-latin character sets, and the lack of authentication allows the proliferation of unsolicited email and malware. Because of the large installed base of MTAs, previous attempts to upgrade it have failed. Therefore, our system was required to support encryption, non-latin character sets, and authentication. It is essentially a private email system. To create a highly secure mail system, the design parameters required a minimum of 256 bit encryption keys, no keys to be stored, and no ability of the server to easedrop on message contents. This required both parties (sender & receiver) to be connected to the server at the same time.

How this works is when one connected party (A) wants to send a message to a second connected party (B), the party (A) sends a request to the server. The server then sends the Public ECC key from party (B) to party (A), and the Public ECC key from party (A) to party (B). This allows each party to create a new Shared Secret to encrypt messages and attachments. Those encrypted messages are passed through the server, but the server has no knowledge of the derived key. The message/attachments are stored encrypted, and the derived key is further encrypted and stored with the message (both sent & received). The only way to view an attachment is via the Msg program using the default program associated with the file extension. There is no limitation on the default program storing the attachment unencrypted.

All this security would be useless if a bad actor gains access to the computer running the software. Therefore, a password is required to access any stored element. That password is stored as an encrypted hash.

When a computer goes to sleep, the connection to the server is no longer maintained. But the socket itself will not have been closed, and the server will think the user is still connected. Each Tray program contains a Heart Beat routine that periodically sends a one byte record. As long as the server receives that record, it will maintain the connection. If it doesn't, it will close the connection. When the Client comes back online, it will detect that the connection is no longer valid, and reconnect. The intention is to have the Client always connected to the server when he/she is active.

When a message is received from the server, a balloon message instruction will flash.

Clicking on the Tray Icon removes the flashing message and activates the Msg program.

So how do we send a message. Clicking on the "Send Message" button brings up the "Send Mail" window.

The To:, Subject:, and message fields are required. To assist with the To: field, the "Get Connected Users" button will return the currently connected users. Clicking on one of those will add it to the To: field. To send a message does not necessarily require the recipient to be currently connected. You can send a message to a valid recipient. It will be saved unencrypted, and when the recipient eventually connects to the server, the message will automatically be encrypted and sent, and saved in the Outbox encrypted with the "S" flag set.

You can also reply to a message by clicking the "Reply" button while reading a message.

In this case, the To:, Subject:, and marked up message will be automatically provided. I chose to provide top posting by default.

Because the UserID is sent unencrypted, it is essentially public information and can be sent to the server operator by any available means (eg email) for the purpose of signing up. The Password on the other hand is private information, and should not be transmitted using any insecure communication method such as standard email. The server cannot use the password anyway, so there is little point in sending it unencrypted. The normal technique for handling the addition/modification of user login information is to use a secure server capable of supporting TLS. To permit useage without this capability, the server software contains code to log the password hash for an failed login using a valid UserID. The server operator can then add that hash to the user database using sMsgCtrl. The program uses a random shuffle of the hash bytes before storing it.

These programs in theory support non-Latin character sets (eg. Chinese/Arabic), but these have not been tested extensively.

The client and server also support IPv6, but these have experienced very limited testing due to the lack of a native IPv6 network.

Both downloads contain a ReadMe.txt file to further explain installation and useage.

NOTE: The Cryptography routines will probably work on all versions of Windows, but the TCP/IP portion of the program will only work on dual stack systems that support both IPv4 and IPv6. This more or less restricts it to Windows Vista or later.

Back to Top


| Home Page


address