|GUI ScreenIO Client/Server|
If you are using the licensed client, or our Secure Server Feature, all data transmitted between the client and the server will be encrypted. The implementation assures that your data in transit will be as secure as any other application that uses standard encryption techniques.
GUI ScreenIO uses the strongest encryption that is approved for export by the US government.
The essence of secure cryptography is that the security should rest in the key, not the algorithm. If the algorithm is a good one, it will be impractical (effectively impossible) for an attacker to decrypt the data stream without knowing the key, even if the algorithm is known.
GUI ScreenIO presently uses the RC2 block encryption algorithm with 128 bit keys. The encryption implementation used by GUI ScreenIO allows the use of other encryption algorithms, and there is no guarantee that RC2 will be used in future versions of the client/server software. We use the strongest standard Windows cryptographic routines as provided by Microsoft.
The only way to read the encrypted message (assuming the algorithm is a good one) is to try decrypting the message with each one of all possible keys. This is called a "brute force" attack. If the key is long enough, it will take so long to test all possible keys that it's impractical/too expensive in the real world for any organization with limited funds (which excludes governments, of course). Such an encryption scheme is effectively secure.
For example, if the key is 8 bits long, there are 28, or 256 possible keys; it obviously wouldn't take long to try all of them and to read the message. However, if the key is 128 bits long, the number of possible keys is 2128, a very large number.
Given the speed of computers available today, it's not practical for an attacker to use a brute force attack to eavesdrop on a message encrypted with a 128 bit key.
GUI ScreenIO's implementation generates a new, unique, random 128 bit key for every client/server session, and for every job launched by the client.
If your server is running sessions with 100 different clients, each client is using a different key; therefore, if an eavesdropper managed to obtain the key for a given session, it would be useless for eavesdropping on any other session, or on a subsequent session for the same client.
All real-world encryption systems use symmetric keys; that is, the same key is used for both encryption and decryption.
One very good approach is to create a new key for every session. This makes it impossible for an attacker to discover the key in advance. But, how do you pass this key to both parties without risking exposure to a third party; e.g., an eavesdropper? The solution is both simple and elegant.
You may have heard of public-key cryptography; this is a system whereby a user publishes a key (a "public key") that is used by others to encrypt data, which is then sent to the owner of the public key. The recipient decrypts the message's ciphertext using the private key that corresponds to the public key used to encrypt the data; the private key is kept secret and is known only by the recipient.
Public key cryptography is very secure but is very slow (because of the extensive computations required), so it's unsuitable for encrypting and decrypting large amounts of data. But, it's ideal for passing small amounts of data (like a session key) between a client and server.
Session keys are unique keys using a fast cipher methodology of medium length (128 bit), which have a valid life span that is very limited. The server will only honor any given key for one login and menu delivery. A new session key is generated for every job requested by the client, and every 10 minutes of idle time at menu.
Connections from Licensed Client (or all clients when using Secure Server Feature) to the Server go thru several steps:
Our server requires exactly ONE incoming port be open to the outside, and the only thing we accept on this incoming port is a login request in a specific form. ALL login requests are encrypted, requiring the negotiation of one-time session keys. Jobs are only encrypted if Secure Server Layer or licensed clients are in use.
Our Clients require NO incoming ports be open. They do require the ability to open random high ports for outbound connections to the Server. This is consistent with all other applications that can access remote servers, and is honored by all firewall software. The client does not LISTEN on any ports.
Encryption takes care of eavesdroppers, but it's also important to protect your application from intruders who access it by imitating a legitimate user. GUI ScreenIO authenticates users in several (optional) ways:
You might think that all your data security problems are solved at this point, but we've only addressed the security of the data communications in our products, not your network in general.
It's well beyond the scope of this document to address data security issues in depth, and encryption is only part of the solution. If your application is truly sensitive, you should consider engaging a professional security consultant to help you.
Nothing in the client server layer prevents you from adding a Virtual Private Network link, another form of data encryption from client to server, as an additional or alternative to our encrypted data stream. (Although, counter-intuitively, encrypting already encrypted data does not yield better security).
Encryption and data security are a complex subject, and for those of you interested in learning more about it, we suggest the following books:
For a far more comprehensive view of data security,
|© 2000-2006 Norcom, all rights reserved|