dcsimg
Results 1 to 1 of 1

Thread: (VB6) - Secure Messaging

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    601

    (VB6) - Secure Messaging

    I developed this set of programs quite some time ago, but I wasn't sure how to proceed with it. It was developed to get around some of the limitations of the existing email system. 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 (Mail Transport Agents), previous attempts to upgrade it have failed. Secure Message was designed to support encryption, non-latin character sets, and authentication. It is essentially a private email system. To create a 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 ease drop on message contents. Because of how ingrained the SMTP (Simple Mail Transport Protocol) protocol is in today's society, the only viable option is to provide a secondary alternative to be used in parallel to the existing system. I am not na´ve enough to think that these programs could be that alternative. They are being presented simply to demonstrate that alternatives are possible.

    To produce these programs, I borrowed parts of it from JACMail, parts of it from Sample Tray Activation, and parts of it from various Service programs. I also used my own encryption library (JCrypt.dll) for convenience only. This encryption library has proven to be too slow for practical consideration in any final solution.

    Connection to the server uses 256 bit ECC (Elliptical Curve Cryptography) and a UserID and Password. As in most password protected systems, the UserID is public information and is sent unencrypted. The password is private, and sent encrypted. ECC eliminates the storage of keys, and is different with every connection.

    That takes care of the authentication part, but to prevent the server from being able to ease drop required a slightly different approach. When connected party (A) wants to send a message to a second connected party (B), 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 downside of this approach is that both parties (sender & receiver) have to be connected to the server at the same time. 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.

    Secure Message is a Client/Server application. The main server component runs as a Service, has no visible components, and operates with system privileges in Session 0. A small management program (sMsgCtrl) is required 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 with a small window, but does require the NT Service Control (NTSVC.ocx). To create the Service, change the "IsService" flag to true and compile under a different name. The Desktop server requires a "\Logs" sub directory, but the Service logs to "\Windows\System32\Logfiles\sMsg".

    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 the database functions. Msg.exe can be activated by clicking on the 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 the mouse above the Icon. If not currently connected to the server, the Icon background will be red.

    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 a shuffled 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. Therefore, the connection is closed on the client end when the computer goes to sleep or is shut down. In addition, 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, or the user can right click the Tray icon and reconnect manually. The intention is to have the Client always connected to the server when he/she is active.

    When a message is received via the server, a balloon window will appear, along with an audible if the "Notify" sound file has been enabled. Clicking the "X" will close the balloon, but to view the message the user must left click the Tray icon to activate the Msg database program.

    A message to be sent is prepared in the Msg program, but is sent to the server by the Tray program. This requires some form of communication between the two programs, which is accomplished using subclassing. The Msg program uses "user32.dll", and the Tray program uses "ComCtl32.dll". Why the difference? Before the Tray Icon program was developed, I used "user32.dll" for the subclassing between 2 desktop windows. The Tray Icon program was developed using dilettante's SubClasser module, which utilised "ComCtl32.dll". It was easier to modify the SubClasser module to process other types of messages than the other way around. Both subclassing systems work equally well in this application, but users should be aware that stopping either application while processing system messages will likely cause the IDE to crash.

    The normal technique for handling the addition/modification of user login information is to use a secure server capable of supporting TLS. To permit usage without this capability, the server software contains code to log the password hash for a 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.

    Both downloads contain a Readme.txt file to further explain installation and usage.

    J.A. Coutts
    Attached Images Attached Images    
    Attached Files Attached Files

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width