In today's lecture, we will discuss an important issue in e-commerce -- SECURITY. The security issue arises naturally from the basic problem of anonymity and openness over the network or by any electronic means. That is,

• "I don't know who you really are!!"
• "Is somebody listening to our private conversation?"

Technologies are available for providing the needed security for doing business electronically. We will review some of the key technologies today:

1. Encryption
2. Digital signatures
3. Digital certificates
4. Secure links using Secure Socket Layer (SSL)
5. Public key infrastructure (PKI)

Security is probably the number one barrier to the growth of e-commerce. Some questions to begin with:

1. How does the customer know that the company is trustworthy?
2. What guarantees are there that the company will still exist tomorrow?
3. How does the trader know that the customer is not using a stolen credit card?
4. How do both sides be certain that the transaction has actually taken place and did so privately without being peeped by someone else?
5. How do both sides be certain that no private information has been leaked during the transaction?
6. If things go wrong, what kind of evidence can be used to provide support to both sides to ensure a fair settlement?

1. Confidentiality -- Data must be maintained confidential
2. Authentication -- Business parties must surely know each other's true identity
3. Integrity -- Data must be correct and not damaged
4. Non-repudiation -- Business transactions must be proved of their being taken placed (not easily denied). This is still an open issue. Under current laws, if a document is proved to have been sent by the postal system, that is a legal proof already. But for e-commerce, we still do not have a legal precedent but the legislation in many countries is actively considering the mechanism to prove when and to whom an item has been sent.

The solutions we have to these problems are basically built around two basic ideas:

1. Encryption -- to ensure that communication is protected
2. Issues of digital certificates -- to assure the identity of people or business parties

The are many forms of security attacks that can take place in the distributed environment.

1. Direct attack The hacker logs on a computer system and runs applications as if he/she is a bona fide user of the system. This kind of attacks is mainly done by stealing or guessing passwords, or through an innocent user who has been deceived to run a Trojan Horse which opens up a backdoor.
2. Denial of service The hacker does something to prevent the normal operation of a network or a server. Common forms of denial are 'eating up bandwidth' (ping of death) and 'connecting server' (TCP SYN to inhibit access to TCP/IP sockets), etc.
3. Loss of privacy Sensitive and important data are tapped (seen) during transfer. Typical tools are LAN sniffers and WAN datascopes.
4. Data modification Sensitive and important data are modified during transfer. Hackers try to correct data that may damage the interest of the legitimate party, e.g., a hacker changes a credit transaction amount from $1000 to $10.
5. Masquerade The attacker pretends to be some legitimate server or company by creating a website of similar address, thereby to collect information or defame a company.
6. Information gathering Using some scanning tools, such as SATAN, the attacker can find a host that has weak security.

The problem is that all these hacking tools are available from the Internet, and people can learn to see them very easily.

The basic aim of encryption is to provide secure data transmission through a public network.

The simplest form of encryption is to manipulate on the data through an algorithm which is known only to the sender and the intended recipient. But if the algorithm is known by other people, the security will be broken.

The idea of secret keys

A slightly more advanced method of encryption is to use a "key" to control the algorithm. Here, the key contains some parameters for the algorithm. Without knowing the key, the algorithm cannot be run to retrieve the data.

There are two approaches for managing keys:

1. Private key cryptography
2. Public key cryptography

Private key cryptography (symmetric cryptography)

A secret key is used by both sender and recipient to encrypt and decrypt the data. Examples: International Data Encryption Algorithm (IDEA) and Data Encryption Standard (DES).

DES uses a 56-bit key. First, it is extended to 64 bits by adding 8 parity bits. Then, it is used to encrypt the data which has been cut up into many 64-bit blocks. The encryption is to run an algorithm over the 64-bit blocks, basically mixing them with the key through some bit-operation such as ex-OR and shifting. DES is usually implemented by software, although it was originally designed for hardware realization.

Public key cryptography (asymmetric cryptography)

In public key cryptography, a pair of keys are used. One is a private key which is only known to a person and the other a public key which can be known by the public. Basically, data encrypted by a private key can only be decrypted the corresponding public key, and vice versa.

Normally, if we want to make sure a person truly receives a message, we do the following: we send a message to a person encrypted with that person's public key. When the person gets it, he/she can decrypt it with his/her private key. This ensures confidentiality.

Moreover, if we want to assure the recipient that we are the true sender, we do the following: we encrypt a message with our private key, and the recipient uses our public key to open it. This is the basis of digital signature. A few slides later, we'll explain it in more detail.

Mixed key systems

Private key systems are more popular because they are simpler and run faster. Public key systems are slower and used for more specialised applications such as digital signing and "transmissing a private key." Thus, many practical applications use a combined private key and public key systems, to take advantage of the better security of the private key system and the fast algorithm of the public key system. A typical example is the SSL (Secure Socket Layer), in which public key encryption is used to exchange the private key. See below.

To break the system, one has to guess what the key is. This can be done by a fast computer trying all keys one by one. The question is:

How long do we take to try all the keys and crack the system?

Let's look at a simple formula. Quite generally, we expect the time needed to guess a key to be proportional to 2^(number of bits), i.e., 2^(key length). If the key attempt rate is N per second, then the time needed to crack the key is

Time = { 2^(key length) / 2N } seconds

Consider the 56 bit DES system. If we have a computer that can guess 2^(47) keys per second, then we need about 5 minutes to crack the key!!! This was exactly tested by a US company who built a DES cracker with an investment of US$210,000!!! -- the Deep Crack project.

That sounds pretty bad! Let's now consider a 128 bit system. Suppose we have five times more computer power. Using the formula, we need about 74 billion years to crack it. That's pretty safe in fact!

The point is that if computers get faster, we need longer key length to ensure adequate security. However, we cannot just use a very long key just to prevent cracking because long keys are not efficient and the encryption and decryption times can be very long. Thus, we need to set the key long enough to prevent possible cracking, but short enough to allow fast encryption and decryption.

DES can be enhanced to improve security. We have now Triple DES, which basically has three keys, hence 168 bits altogether. The cracking will be quite impossible (requiring a million years with present computers.)

The purpose of a signature is for identification of the person who signs it. The recipient, seeing the signature, can be sure of the sender's identity.

How to do it electronically?

Suppose I want to send a message to David with my digital signature. The mailing software will do the following:

1. I write the message.
2. The software creates a 20-byte digest from the message.
3. The software encrypts the digest with my private key.
4. The message together with the digest is sent to David.

When David receives the message, his software has to do the following to verify the signature:

1. The software creates the same 20-byte digest from the message.
2. The software uses my public key to decrypt the received digest.
3. The decrypted digest is compared with the generated one.
4. If they agree, then the message can be sure to be sent from me.

One-way digest generation

One very important part of the procedure is the digest generation which MUST BE a one-way process. You can't reverse it, and you can't (very hard!) generate the same digest with a different message. In fact, the digest creation algorithm is designed to make sure that a slight difference in the message can give different digest.

NOTE: Strictly speaking the digest generation is not one-to-one, but because the number of possible digests is large, we may say that the digest generation is nearly or practically "one-to-one"!

The SET (Secure Electronic Transaction) used for credit card transaction throught INTERNET uses this method.

As we have seen from the above description, the public key infrastructure can provide a good security solution for transferring data through the network. There is, however, a problem of trust which is still not resolved. How do I know if the public key really belongs to the person (or the bank) not a imposter? How do I know if the web site is really American Express?

We need to certify a person's or bank's public key by a third party who can be trusted. VeriSgn Inc is one such trusted body.

Basically to certify a site or a body is to "digitally sign" the public key and other personal information by the trusted third party. That is, "the public key and personal information" is the message to which the above-described digital signing procedure is applied. The resulting encrypted message is called a digital certificate.

QUESTION: WHO CAN CERTIFY THE SO-CALLED TRUSTED PARTY?
The industry solution is to let the trusted party "self-sign" its own certificate. [Interesting logical flaw that is widely accepted!]

There are currently some pretty good ways to protect an Internet link or session. A common approach is to use a Secure Socket Layer (SSL) which was developed by Netscape.

SSL is based on public/private key encryption to establish a secure web session between the server and the user. In fact, SSL can be generally applied to any communication between two parties. It actually is an extra layer sitting on top of the usual TCP/IP.

SSL tricks

1. Both server and client can verify each other's identity
2. Intruders cannot pretend to be either party
3. Application transparent

URL with SSL

Any URL beginning with https indicates that the session is protected by SSL. Usually the port number for SSL communication is 443 (rather than the default 80).

Other approaches

There are other methods to achieve security in HTTP, for example, by using the "basic" authentication feature. If supported by the HTTP server, the header

WWW-Authenticate: Basic realm="something"

will cause the browser to pops up a dialogue box prompting for a user ID and password.

Alternately, we can use a CGI program to include a password prompting procedure before the browser can enter the homepage. This method is used for protecting these notes. The CGI is "htpasswd".

Public/private key pairs provide an effective mechanism to secure transmission of data. The management of keys then becomes an important issue if security is to be ensured ultimately.

There are some basic questions for managing keys:

1. How to reject a certificate from someone who is no longer trusted?
2. How to backlist untrusted people and companies?
3. How to replace lost private keys?
4. How to gain access to encrypted messages which are sent to an employee who is no longer trusted?

For example, a large company needs to keep all the certificates of their employees in some kind of email directory. So, if one employee wishes to send a message to another, he can first look up the directory to verify the recipient's certificate. So, the company can delete or revoke an employee's certificate.

Furthermore, should then company keep the employees' private keys? Maybe it should, in case an employee's private key is lost due to a hard disk failure, for example. The company may also need to see encrypted messages sent to an employee who has left the company or is not trusted.

In this lecture, we have reviewed the security problems associated with doing business over a public network.

The main purpose today is to introduce some key technologies for network security. These include:

1. encryption of data
2. private and public key cryptography
3. digital signing
4. digitial certification
5. public key infrastructure

Further reading:

• http://ecommerce.ncsu.edu/topics/security/security.html