Quote:
Originally Posted by Dusty
How does that work?
|
In a system I developed, we had secure and un-secure methods of transmission. Since the only major differences were encryption and failed message delivery, I'll just point out the overview of how our systems operated, securely, in a Peer to Peer email system.
Let's say that Dusty wants to send an email, bragging about a recent barehanded pig kill where he jumped out of a tree with a knife between his teeth, to Barbarian. They each have their own laptop (we'll call each laptop a node) and are connected to a network (even this can be secured or not). For grins, let's say they are on a public network. Each node has a unique ID. This unique ID, or node ID, is registered in an encrypted data store. An application or background look-up service (as I refer to it) provides authentication and queries to this list.
Each person has an email address that has been bound to a certificate provided by a trusted third party. Each certificate contains a public key. The assumption, at this point, is that each person has access to a private key on their computer (used later to decrypt the encrypted message they receive).
Using the custom email application that has been tailored for this sort of thing, the inbox only stores notifications that a message has been received. The content of the actual message is not stored in this notification. However, it resides elsewhere in a secured manner with a special id. Later on, you'll see some benefits to this.
Message Creation:
Dusty creates a new message and types in Barbarian's email address. The look-up service is running in the background and authenticates Barbarian's email address and retrieves the key associated with it; extracting his public key.
A session key is generated and used to encrypt the contents of the message. Next, a message ID is generated in order to uniquely identify the message (for retrieval OR as our clients love this feature - removal prior to or after a message has been sent). Ever send something to the wrong person? Or wish you could truly recall a message? Well, now you can if you utilize this. It's no longer "throw it over the fence and wait for the boom". Some of our messages have expiration timers and that sort of thing. Also, they can't be forwarded if that user does not have the rights to forward their messages or a particular message that the sender did not want forwarded.
Once the message is mapped to a key and everything is encrypted and ready to be "sent" - remember, the message body and notification are two separate entities, then the encrypted message is stored on the closest node. In order for this to work, in real time, the nodes have to be powered on and connected. After the message has been sent, the retrieval function will begin.
Message Retrieval
Barbarian cranks up his email client and checks for new messages. How? The app queries the background/look-up service to find any missed messages so that it may be synchronized. This background service keeps a tab on available nodes at all times, complete with any messages that are destined for Barbarian.
If an email has been obtained, then that message is retrieved and decrypted with the session key that the original sender inserted into the message. The original sender is unaware of this, as is the recipient, since the application does this for both parties. All they ever see is a computer screen with a slick little form.
Upon successful message reception, the background service updates itself so that it won't deliver the same message over and over. This is where things can get fun. Remember when I said that a sender can zap an errant message or prevent that message from being forwarded and shared? This is where that technology is leveraged. True, it must also exist in the email client, it is the actual service that plays God.
There's a WHOLE lot more to this than what I typed. I wanted to provide a mid-level view of my particular implementation of P2P emailing capabilities.
Please bear in mind that there are other ways of achieving this. I've written direct socket communication apps (think chat/instant messaging) and I've written apps that require a physical interface, such as a dongle with encrypted information on it, that must exist in order to authenticate the sending and receiving of messages. The sky is the limit.
BTW...I would bet my next month's pay that my way is not the best way, but I know it works. There are many before me that are truly the experts in this field. I'm sure some 13 year old at MIT could do this in her sleep. I just had to throw something together for a client when we were dealing with an extremely sensitive issue and time, as well as urgency, was a critical factor. Since then, things have evolved.