- Differentiating the Authorities
- Defining the Privacy Problem
- Certifying the Participants
- Doubling the Handshake
- From Theory to Application
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Defining the Privacy Problem
Network security has a particular problem: an open (insecure) channel is a back door for cracking an authenticated link. For instance, programs never should send passwords unencrypted. But passing information to/from sites in a public setting like the Internet is commonplace. And the Internet is the last place for a private conversation.
The Internet's power causes the privacy problem. Built in Cold War paranoia, it was designed to adapt quickly to lost segments, paths, and networks. This means that a message can go in and out of the network's equivalent of a no-man's land. In this region, networking perps snoop messages and try to take over (or hijack) a connection. If a message looks interesting, the cracker may investigate more and even try to entice the local routers to direct traffic toward the cracker's segment, making it easier to see more data. If every connection were directly connected to the desired server, the problem would be not as severe. Instead, you can add some level of privacy to your programs with encryption.
Encryption is not a 100% silver bullet and will only provide a degree of privacy. Different encryption algorithms (or ciphers) scramble the data to apparent randomness, making snooping difficult. However, as technology progresses and as computers grow in computing power, the snoopers can apply more resources to crack open the critical messages.
A wide variety of ciphers are available; depending on your country's laws, you may be able to use them internationally. Ciphers come in two basic forms:
destructive (or lossy)—Data going in does not come out.
nondestructive (or lossless)—The data is recoverable.
The Telnet program, for example, uses a lossy encryption for authentication because the server only needs to check against a known value (the garbled password). Unknown values (the store doesn't know your credit card number until you supply it) require a lossless cipher. Lossless ciphers fall into two groups: public key encryption and symmetric (or secret or private) key encryption.
Symmetric-key encryption uses a reversible algorithm that scrambles and unscrambles using the same key. The sending and receiving hosts share the key. Of course, no one else can know the key (hence secret); otherwise, someone could get to the data. Symmetric keys serve best after the two host computers have completed the certification and are ready to perform transactions. They're relatively fast and very secure.
Public-key encryption, on the other hand, is like a special drop box: It uses two keys, one for encryption and the other for decryption. The server hands out the encryption (public) key, and the clients use it to encrypt sensitive data for the server. The server accepts the data and decrypts the data with the decryption (private) key. This is a very clever and useful tool for the Internet—everyone can get a copy of the public key, but only the issuer can decrypt the messages. However, public ciphers are about 10 times slower than symmetric-key ciphers and are less than one-quarter as secure.
Network privacy continues to drive the technology. The speed, reliability, security, availability, and portability of the ciphers force scientists to more creative solutions. The networking industry recognizes that privacy is crucial to connectedness, and if they want to remain connected they must adopt technologies that ensure data integrity and protect internal networks.
Of course, the client also wants his/her information protected, but often leaves privacy protection in the hands of the service provider. This has led to some data privacy and usage statements you may have seen on the Internet and elsewhere. As the designer, you must work within the confines of good sense to protect users' privacy (consulting your corporate ethics and security groups may give added insight). One bad example was when one company's site asked for the user's social security number (SSN), but not the email address. They felt that the email address was more personal than the SSN. Clearly, besides common sense, legality is an important issue as well.