December 31st, 2001, 08:40 PM
Secure Email Transport Authentication Protocol
For immediate publication:
30 December 2001
Tampa, Florida - 30 December 2001 – New Security Hardened Protocol Replaces SMTP In Corporate Environments.
When your executives want to send email, use SMTP. When they want to send highly classified corporate data, use SETAP.
SETAP (Secure Email Transport Authentication Protocol) is a network Email Server protocol that incorporates 2048-bit 4AES Encryption for secure data transmission; a virtually infallible method of client authentication without the use of certificates that may be intercepted and forged; and utilizes Random Data Ports over a 2048-bit 4AES Encrypted Channel using a Unique Session Key for each transaction.
CTD Technologies' patented SETAP Server appliance is built entirely around SETAP. Incorporating some of the industry's finest intrusion detection, monitoring and firewall technology, SETAP Server offers a new standard for pro-active security-hardened network Email delivery. In most network environments, standard Email serving methods are highly vulnerable to compromise and are extremely time-intensive to set-up and maintain even a low-level of protection. The SETAP protocol along with the SETAP Server provides for automatic registration, pro-active system protection against intrusion and little administration.
Knowledgeable hackers know every exploit for every security standard that you are trying to implement. With SETAP, we set out to redefine those standards and in the process came up with an extremely challenging protocol. I take pleasure in knowing that this protocol does not play by the rules at all, says Michael Vaughn, Chief Software Architect for CTD Technologies. Virginia Guiler, VP of Research and Development for CTD Technologies additionally comments, As processor speeds and bandwidth increase rapidly in our connected world, secure communication becomes a necessary resource that requires absolute authentication and accuracy. The SETAP protocol and SETAP Server were designed for precisely that purpose.
More information about SETAP and the SETAP White Paper are available on our server: http://ramdog.netfirms.com
December 31st, 2001, 09:16 PM
Mankind have a great aversion to intellectual labor; but even supposing knowledge to be easily attainable, more people would be content to be ignorant than would take even a little trouble to acquire it.
- Samuel Johnson
December 31st, 2001, 09:18 PM
Hmmm, talk about making money of the paranoid. I need to read more on this but there is such a thing as fool proof and foolish. Below is my reasoning behind this:
1) Proprietary Algorithm and Equipment (why slave yourself)
2) No backwards compatability (No go for wide spread use)
3) Filtering IP after one failed use (do you wanna be the admin to clear up that mistake?)
The nice things I like is the unique sessions and random data ports. My view on all this is that would probably be enough to secure your mail.....assuming that you have already put restrictions on the ability to monitor your media (switching while watching arp etc....) This is a setup designed for a private mail exchange that would be used exclusively for a large corporation that is VERY paranoid about e-mail. Good for banks maybe? Requires client side software to be installed and the dedicated mail server to be linked to each station. Secure as hell, but to restrictive.
January 1st, 2002, 12:13 AM
Anywhere I can obtain a progarm that uses this technology?
January 1st, 2002, 02:11 AM
January 1st, 2002, 02:58 AM
Just kidding :)
I do not have a demo for release or stand-alone program. As such, it is a system that relies upon other components to operate as intended. It's quite a piece of work
I set out to hopefully set a new standard of security whereas an application is responsible for defending itself instead of relying on external resources. Interesting concept, eh?
Glad you find it interesting
January 1st, 2002, 08:10 AM
This is an interesting protocol. What I do not agree with is it's dependancy on the client and server type setup. This would be beyond a perfect setup for a small business that needs absolute security across e-mail. But not a solution for an individual user. I am under the impression that you install the client software onto whatever hosts you may want. From there you actually are prompted to hardcode the IP address of the server that you wish to connect to sendmail. From there we are dealing with an intranet type setup where the protocol is proprietary so the only ones that can use it are the ones with the client software setup. This seems to be good for busness (selling licenses etc...) but really shitty for any hope of this protocol to ever be in the hands of ordinary users that wish to secure a mail connection (lets just say point to point). Regardless, like I said, niffty lil proddy but is there going to be any adaption towards a smaller scale?
January 1st, 2002, 12:40 PM
That was a very good question, and I'll try to give you a good answer.
Corporate espionage and sabotage are rampant. For instance, the Biotech industry is at war with itself as competitors try and get intelligence on what patents the other companies are working on. The banking industry, though they will never admit it publicly, is loosing a large amount of money from intercepted and decoded transactions. SSL is a joke.
Another use of this would be field agents communicating with their home offices.
A packet sniffer can easily monitor all data that leaves or enters someone's NIC card. The FBI can install Carnivor at the ISP level and harvest data.
There are many solutions available today for the public at large: PGP, P3P, SSL, etc.
However, there are times where a company may have a need and desire for the strongest protection that technology can provide, and they should have it.
Sure, I admit that this is a hardcore protocol almost to the point of insanity; I set out to build it just to see if I could. And I had a lot of fun doing it also. However, getting the client/server synchronization working took a few years off of my life, it was a rewarding experience once it all flowed together.
I haven't had any sales yet because it hasn't been out yet a week, and most people do not even know that it exists. All I can do is hope that someone out there will find it to be a fun toy and order it.
January 1st, 2002, 01:02 PM
Interesting. But I notice that yet again you have to have some client software for ultimate protection.
Many organizations try to capture the secure-mail market. In Norway, the postal services have implementations of protocols similar to this one. Of course that is because of the smaller amounts of buisiness snail-mail, and trying to stay ahead of the market.
As far as I know, you have to have some client software also in their solution, to be able to use a good enough encryption algorithm. The mail is not sent directly to the reciever, but is bufferd in the postal office's server, so they can guarantee that the mail comes from the sender and is delivered to the reciever. The system is quite exciting, but not very easy to use at this point, because of you have to have the client software, and also a special e-mail address provided by the postal services.
The idea is to create a system that will be approved by the goverment to use with govermental documents, such as tax papers etc. Together with this, an implementation of electronic signatures is also under development. The idea is that when able to send important documents with e-mail, they could also be signed electronically. Perfect for signing contracts etc.
But there has to be a third party involved, and also client software. We know that to this date there is no fool-proof solution without this overhead.
January 1st, 2002, 02:56 PM
Very good point, and yes, client software is needed. The reason for this is that it is a proprietary system. It needs to be proprietary because of the mechanics that are involved. The client software must be able to assemble the authentication package on each run, as well as utilize my Rijndael implementation 2048-bit 4AES. There is nothing available commercially that can do this. Also, the client must accept a call from the server to validate the IP on a random Secure Channel. So at this point it has to be a closed system.