dcsimg
Results 1 to 5 of 5

Thread: (VB6) - Secure Messaging

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    669

    (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

  2. #2

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    669

    Re: (VB6) - Secure Messaging

    Version 2 uses a modified TLS 1.3 encryption process. I say modified because that process was basically designed for a Client/Server type of operation. Secure Message is a Client to Client process, with the Server acting as an intermediary.

    The purpose of the Server is to authenticate the individual Clients, and to forward encrypted messages from one Client to another. The only cryptographic function performed by the Server is to decrypt the password information from the individual Clients. The rest of the time it simply forwards whatever it receives. The passwords are stored in a database as a shuffled SHA256 hash.
    Code:
    CLIENT 1                    SERVER                   CLIENT 2
    
    Client Hello  ---------->  |      |  <-------------  Client Hello
      (ECC Public Key)                                     (ECC Public Key)
    Server Hello  <----------  |      |  ------------->  Server Hello
      (ECC Public Key)                                     (ECC Public Key)
    Gen Key               Gen Key    Gen Key             Gen Key
    Encrypted PW  ---------->  |      |  <-------------  Encrypted PW
                           Verify    Verify
    Connected           Connected    Connected           Connected
    
    
    Msg Request   ---------->  |      |
    ECC Public Key <---------  |      |  ------------->  ECC Public Key
     (Client 2)                                            (Client 1)
    Update Session Hash                                  Update Session Hash
    Gen HS Keys                                          Gen HS Keys
    Finish (Encr) ---------->  |      |  ------------->  Decrypt
    Decrypt       <----------  |      |  <-------------  Finish (Encr)
    Update Session Hash                                  Update Session Hash
    Gen AP Keys                                          Gen AP Keys
    
    AP Msg (Encr) ---------->  |      |  ------------->  Decrypt Msg
                                                         Save Header
                                                         Encrypt Body
                                                         Save Body
    In the generation of the HS (Handshake) and AP (Application) keys, as well as the transmission of the Application data, the Sequence Number is combined with the IV (Initialization Vector) to form the Nonce used in the encryption process. When the Message Body is stored in the database, the ID Index is used in place of the Sequence Number. In both cases, this ensures that the Nonce is unique.

    The recipient does not have to be logged in to the Server to receive a message. The message will be stored in the Outbox unencrypted until the recipient connects to the Server. The Sender will periodically scan the Outbox for unsent messages and attempt to connect with each one. If the Server reports that the recipient is online, the Sender will encrypt the message, send it, and then encrypt and save the Body of the message. The header utilized is similar to standard email.
    To: Recipient
    From: Sender
    Subject: Test
    x_Mailer: sMsg Version 2.0.0
    Date: Sun, 11 Nov 2018 13:19:34 -0800 (PDT)
    Message-ID: <43415.576087963@MsgServer>

    The program also supports attachments, as long as they utilize standard file extensions (.txt, .png, .mdb, .doc etc.). An attachment is first decrypted using the keys and Sequence Number associated with the transfer. Then it is encrypted using the keys and ID associated with the stored message. The only way to display the attachment is via Secure Message. The file is decrypted and then passed to the default program associated with the file extension. There is no restriction on the default program storing the decrypted file in a separate location.

    The Client program will support web links in the body of the message, but does not support embedded objects or HTML. It also supports spell checking, and in theory supports non-latin character sets (eg Chinese, Arabic). All messages use full Unicode.

    The Client program actually consists of 2 programs; one called Tray.exe, and one called Msg.exe. Tray normally resides in the System Tray of the Task Bar. When first installed, it may have to be dragged from the hidden portion to the visible portion. It will attempt to connect with the server, and if successful the red background on the Icon will be removed. Hovering on the Icon will display it's current status, and clicking on the Icon will activate the Msg program. The Msg program handles most of the database functions, and Tray handles all of the network communication functions. This requires the ability of the 2 programs to communicate with each other, and this is accomplished using subclassing. Once the Msg program is activated, it can then be setup using the menu on the main form. Further instructions on setup are included in the ReadMe.txt file.

    Even though the Server is somewhat simpler, it does require a little more work to setup. It normally operates as a Service, but can also be run as a desktop application. As supplied, it will compile as a desktop application (sMsgS). To compile it as a Service, change the "IsService" flag to True and compile under a different name (sMsgSvc). In either case it will require setting up, which is accomplished using a separate program called sMsgCtrl.exe. This program must be run as an Administrator as it has to access restricted areas of the Registry and File System. Further instructions are located in the ReadMe.txt file.

    Normally I would use Crypt13.DLL for the cryptography work, but since I cannot post executable programs on this site, I have included the full DLL code as a standard module (mCrypt.bas).

    J.A. Coutts
    Bug Report: As long as the traffic was in the same direction on the same connection, messages would send OK. But if a Client attempted to respond to another Client, the message appeared to disappear. In fact, the message was received but was decrypted with the wrong keys, resulting in not being saved. The line "SetClientFlg False" needs to be added to the SendMail routine in "frmTray".

    Bug Fix: (12/09/2018)
    I discovered that when sending an secure message to a misspelled User name (Invalid User), the sending form in "Msg.exe" did not inform the user that the message could not be sent (it just did nothing). The user should be informed of the problem and given the opportunity to correct the issue. The source of the problem originated in the "Tray.exe" program, and was the result of adding a feature to inform the user of a "Bad Password". The sMsg download has been updated to correct this error.
    Attached Files Attached Files
    Last edited by couttsj; Dec 9th, 2018 at 10:32 PM.

  3. #3

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    669

    Re: (VB6) - Secure Messaging

    The sMsg download has been updated with a bug fix and minor changes to Tray.vbp

    J.A. Coutts

  4. #4

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    669

    Re: (VB6) - Secure Messaging

    The calculation of the encryption keys in TLS 1.3 is very convoluted and difficult to follow. The example traces provided by the IETF:
    https://tools.ietf.org/id/draft-ietf...ectors-07.html
    are helpful, but use "x25519" (not supported by Win 8.1) and do not explain where many of the hash values come from. There are so many different secret names that it boggles the mind. So to make it easier to follow it's usage in Secure Message, I put together the following trace documents:
    Trace1.txt - Client 1 (Admin) - Message Sender
    Trace2.txt - Client 2 (User2) - Message Receiver

    Fixed ECC keys were utilized by adding test code to the "GetPublic" routine in modTray,
    Code:
    '****** Test Code ******
        'bPubKeyIntblob = HexToByte("45434B3210000000" _
                                & "7ED4E43AD378686BBFDCE8CC3594FF4F" _
                                & "C7F2C99B6A80A44E7B20C2864DFD22D3" _
                                & "D3B5A4173F3BC3D07CFE5321C9104F4F" _
                                & "BDB06A6B40B69B77D83743D4D13616F7")
        'bPrivKeyIntBlob = HexToByte("45434B3220000000" _
                                & "7ED4E43AD378686BBFDCE8CC3594FF4F" _
                                & "C7F2C99B6A80A44E7B20C2864DFD22D3" _
                                & "D3B5A4173F3BC3D07CFE5321C9104F4F" _
                                & "BDB06A6B40B69B77D83743D4D13616F7" _
                                & "569CFA76ECE0206BDE121A2AD1D1A36E" _
                                & "49DCF64BD288A4129F832B721DE1FA77")
    '****** END Test ******
    for Client 1 (Admin), and
    Code:
    '****** Test Code ******
        'bPubKeyIntblob = HexToByte("45434B3210000000" _
                                & "DB123FB5F47A0657D7A22A20BFD8EE70" _
                                & "5E551E6AC0B3384914A19872B97AFE35" _
                                & "11F3E10713BFE1E478FED8FEAF0DCEA7" _
                                & "8E72F9C41B301685ED6348E74C40F557")
        'bPrivKeyIntBlob = HexToByte("45434B3220000000" _
                                & "DB123FB5F47A0657D7A22A20BFD8EE70" _
                                & "5E551E6AC0B3384914A19872B97AFE35" _
                                & "11F3E10713BFE1E478FED8FEAF0DCEA7" _
                                & "8E72F9C41B301685ED6348E74C40F557" _
                                & "A601BD05826190592A67A4491E383A50" _
                                & "4FF808C86DD6B8ED45640D0EDD4F78B6")
    '****** END Test ******
    for Client 2 (User2)

    It is best to use a text editor with a fixed font for viewing these traces. Client 1 (Admin) was run on Win 8.1, and Client 2 (User2) was run on Win 10.

    Hope this helps.

    J.A. Coutts
    PS. Tray.vbp download updated with bug fix
    Attached Files Attached Files

  5. #5

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    669

    Re: (VB6) - Secure Messaging

    I would like to promote this project as an alternative to the present email system. This would require a set of standards to be developed. To get to that point, I believe that a good working server application needs to be developed. There is nothing wrong with the server application I have developed, but I don't believe that it will scale very well. A good server application should use blocking calls (synchronous) for socket operations. As well, the decrypting routine I used for decrypting the password hash should probably be more universal. The server function is relatively simple and doesn't necessarily need full cryptographic capabilities, although it may be necessary if automated password update features are required.

    Most of the functionality and the bulk of the code exists in the Client program. What I have developed is something that works on the Windows platform. Once the full functionality of the server is determined, Client programs can be developed in any desired code on any desired platform. This part requires a set of standards.

    And it goes beyond that. Because both parties must be connected to the server at the same time, there is a physical limit to the number of open connections that a server can maintain. But there is no reason that encrypted messages cannot be forwarded between servers. The server plays no role in the actual encryption process.

    I looked into GitHub, but I am wary of using it after the Microsoft purchase. Microsoft has a history of ham stringing parts of purchased companies that don't suit their own purposes. I did download the source code to Source Forge, but got very little response and they cancelled my account without any explanation when I attempted to upload some executable code.

    If anyone is interested in pursuing this, please reply or send me a PM.

    J.A. Coutts

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