Web Security

An outline of Web security is given here.

The Problem

• There are lots of bad guys in the world.
• Files with sensitive information that should not be viewed by anyone except those for whom it is intended are shipped across the Internet all of the time.
  • We often access financial accounts on the Web.
  • When we do, we need to type in a password, account details, and other personal information that could be used by thugs to gain access to our accounts.
  • The password and other personal information are packetized and sent across the Web to the financial institution.
  • It is possible for these packets to be viewed along the way (e.g., by picking up what is sent from our wireless connection) by determined bad guys.

Whatever is one to do?

A Solution—Modern Cryptography

A Scenario

• Often, information we don't consider sensitive can be sent in "plain text" which means that it is sent as it was created. A packet sniffing program could then easily process what was being sent.
• If information is sensitive, it can be encrypted (changed to an unreadable form using cryptography) by a program that is part of a browser or other program at the client side or the server side before it is sent.
  • To access a financial account, we navigate to the financial institution's website with an HTTPS request (the S in HTTPS means that information sent to and received from this website is to be secure, that is, encrypted.
  • The cover page of the financial institution is displayed in our browser with fields in which to type our login user name and password.
  • We type our user name and password in plain text (even if our password is not displayed when we type it, that is only to thwart someone from copying it who is looking over our shoulder; it is still in plain text as we type it and as the undrlying program reads it).
  • The browser then runs a program that encrypts the data we type, including the information and password, before it is packetized and sent over the Internet to the financial institution
  • When the packets are received by the financial institution, they unpacketized into the complete encrypted message.
  • The encrypted message is then decrypted and turned back into plain text by a program on the financial institution's server.
  • Even though the financial institution's decrypting program (and the browser's decrypting program when it receives encrypted information from the server) can decrypt the message, those who would sniff the packets in between don't have the programs and/or the keys for running the program for decrypting what they sniff.
• Thus, sensitive information can be sent across the Internet in encrypted form.  Packet sniffers can still read intercepted packets, but cannot decrypt the garbled content...at least that's what we hope.

Public Key Encryption

Historically, the weak point in encryption has been how to secretly and securely send information about how to encrypt a message to a person who is supposed to send sensitive information in encrypted form back to home base. In recent years a cool technique has been discovered that solves this problem. It is known as pubic key encryption.

• Public key encryption depends on one unique property: knowing the key for how data is encrypted does not help in decrypting a message.
• The public key is not a physical key, but rather data, such as a very large number that is the product of two other large prime numbers (remember that a prime number is a number that can only be divided evenly by itself and 1). This "product of two primes" approach was invented by three computer scientists at MIT: Ron Rivest, Adi Shamir and Leonard Adleman, and is known as the RSA algorithm.
• The public key can be sent in plain text to another computer that has encrypting software installed for this public key encryption technique.
• The receiving computer computer feeds the pubic key (large number that is the product of two primes) and the data to be encrypted into a program that encrypts the data.
• This data is then packetized and shipped back to the original computer in encrypted form.
• Even though the operators of a packet sniffing program might know the large number that was used in encrypting the data, that is not sufficient to be able to decrypt the data.
• The original sending computer then receives the data that was encrypted with the large number. This computer has a decrypting program and the secret two prime numbers (they form the private key) that were multiplied together to produce the original large number sent across to the receiving computer. With those two prime numbers the encrypted message can be easily decrypted.

Issues

Individuals and gangs around the world work non-stop to find flaws in modern encryption systems. As computers get faster, the size of the public key number described above must get larger (to make it impossible for a computer program to calculate the secret decrypting key (the two prime numbers whose product is the large public key number).

Within just the past month of this writing, a flaw was found in a widely used open source (free) encryption technique (SSL - Secure Socket Layer encryption) that had companies scrambling to patch.

The task of the good guys is to keep one step ahead of the bad guys in encryption techniques.

Another Solution—Steganography

This solution is not widely deployed for various reasons. The idea is that sensitive text data can be inserted as part of a file that is itself not a text file per se, such as a picture. The idea works as follows:

• Letters and other symbols in a text file are just bytes of data, where a certain string of bits represents the letter "a" and a different string of bits represents the letter "A", and so forth. So, if a file is to be interpreted as a string of characters, it is opened by a text editor or word processor and the bytes are interpreted to be characters.
• A picture file is also just a file of bytes. However each three byte sequence is interpreted as a color: the eight bits in the first byte of a three byte sequence is interpreted to represent the red component of the current pixel color, the second byte the green component, and the third byte the blue component.
• Thus, depending on how a program interprets the bytes in a file it can be viewed as a text file or a picture file. If a real text file is viewed as a picture file, the picture wouldn't be very pretty, because it would just be random colors for pixels. If a real picture file is viewed as a text file, it too would appear crazy, just a bunch of random characters and spaces.
• However, if one now replaces some of the bytes scattered throughout a picture file with characters of a hidden message, it would just mean that some of the colors of single pixels would be off in terms of the original pictures. Done correctly, it wouldn't even be noticeable by a viewer of the picture on a screen.
• Sending a picture across the Internet would raise no particular concerns unless the sender is already targeted as a bad guy suspect and is under surveillance.
• At the other end, the person uncovering the hidden message would need to know how to interpret certain bytes as characters and others as valid colors.

Could a message be encrypted and then the encrypted characters put into a picture to make it even more secure? Sure. But if the encryption scheme is secure this would be more work than it is worth.

Summary