A Few Remarks on the Security of Electronic Business Applications

Volker Müller

 

Universitas Kristen Duta Wacana                  Universitas Gadjah Mada

Jurusan Teknik Informatika       Jurusan Teknik Elektro

Jl. Dr. Wahidin 5 – 19                    Jl. Grafika 2

Yogyakarta, 55224, Indonesia               Yogyakarta, Indonesia

 

Email: vmueller@ukdw.ac.id

 

 

Abstract:  In this short note I present a few facts on the security of some current Internet applications. Since one strong focus of the First International Workshop on Information Integration and Web-Based Application Services was the usage of the Internet for electronic business applications, I address two applications often used in electronic business: electronic mail (E-mail) and secure access of web pages using the SSL protocol. It should be noted that all the facts presented in the note are well-known to security experts and not new. It might however be helpful for the ordinary user of electronic commerce to become more aware of some security-related problems of the Internet.

 

 

1.      Introduction

 

Worldwide the Internet has grown rapidly in the last few years. From a “mysterious” network for scientists, it has become a part of daily life of “ordinary people”. Even in former so called “less developed” countries like Indonesia many people already use the Internet intensively. One important Internet application is electronic mail (E-Mail), a cheap and fast way of exchanging information. For businesses, electronic commerce is another important application of the Internet.

Every day the newspapers are full of commercials about the best hard/software solution such that a company can make the most money with the Internet. Although the Internet can be of great usage for business between two companies, the common understanding of electronic commerce (in most newspapers) is business between a company and a single person. In this version, a user browses the Internet web page of a company and puts chosen goods into his “basket”. Finally, he/she has to enter a credit card number, which is sent to the company server for validation. If validation and the payment procedure succeed, the goods are sent by carrier to the user. The main advantage of this new way of business is its convenience; people can shop from their home without having to go to a store. In my personal opinion however, this way of shopping “misses something” like the “sensation of shopping”.

 

The main security requirements for Internet applications are often defined as follows[1]:

 

·        Confidentiality is a service used to keep the content of information from all those unauthorized to have it (also often denoted secrecy). An user wants to be sure that his/her private data sent through the Internet can not be “read” by a third unauthorized person (more precisely, a third person can read the data, but does not “understand” its meaning). Confidentiality is especially important for credit card numbers since knowledge of the credit card number and expiration date often already suffices to use the card for small transactions. Therefore information on credit cards should always be stored in a secure way and not accessible to unauthorized persons. Note that this fact is also a problem in “standard usage” of credit cards since most users do not know whether card information is copied or not. In my opinion, this fact should not be used as reason that Internet applications should not be made as secure as possible.

·        Data integrity is the service that addresses the unauthorized alteration of data. In a business transaction, the selling party and the buying party must be convinced that data can not be changed without detection after the transaction is finished. In traditional business, data integrity is usually given by a written paper contract signed by both parties.

·        Authentication is a service related to identification of both persons/computers and information. A user browsing a web page should make sure that the corresponding web page really belongs to his/her business partner. On the other hand, a selling party wants some guarantee that a customer is authentic and does not use faked credit card information (checked with credit card validation).

·        Non-repudiation is a service that prevents an entity from denying previous commitments or actions. In a business application, both the buying and the selling party want to be sure that they have a legal certificate about their business, i.e. neither party can deny any previous commitment.

 

Apart from the technical problems described above, there are also quite a few juristic problems with e-business contracts between “ordinary users” and companies. The main reason for these problems is the fact that the Internet is a world-wide net in contrast to mainly local traditional business. Since there is no obvious way for an entity to determine where a seller’s web side is located; it is not obvious what national law is applicable if there is a legal problem. It should be noted that especially this fact is discussed intensively in the European Union at the moment. With a growing number of electronic business transactions, I also expect a growing number of legal problems, which will cause interesting new challenges to lawyers. The main problem is the lack of internationally accepted rules for valid Internet transactions and sanctions for dishonest businesses. In contrast to standard businesses, opening an electronic business can be done very fast and easily. Dishonest entities can be traced only with some difficulty, since just changing their web page address often enough can overcome easy strategies like black lists. A second inherent problem is the anarchistic structure of the Internet: there is no central authority, which decides and sanctions dishonest practices. I doubt whether “netiquette” alone will be strong enough to overcome these problems.

 

In the following sections, I explain security problems that can endanger the fulfillment of the four requirements from above. I focus on two main applications/protocols: electronic mail (E-mail) and the HTTP protocol used to manage web page access.

 

 

2.      The Main Problem

 

The basic protocol of all Internet interactions is the TCP/IP protocol. All high level applications like electronic mail (E-mail) or protocols like the HTTP protocol for accessing web pages are build on top of TCP/IP. Therefore, all high level protocols “inherit” weaknesses of TCP/IP. Since the TCP/IP protocol was defined at a time where cryptography was not of general interest, the designers of that protocol did not put much emphasis on security:

     TCP/IP sends all information in packets that are not encrypted, i.e. readable for everyone.

     Additional information like addresses of sender and receiver are sent in each packet. Different applications that use the same IP address can differ between packets with so called port numbers. The main security risk is the fact that both IP addresses and port numbers are readable and can be changed.

 

These two main problems lead to the following typical attacks on TCP/IP which are well known tricks often used by intruders (commonly called hackers):

     IP spoofing: an attacker pretends to be some specific host that is different from the correct sending host. This can be done by changing the sending IP address of packages sent to some host. That host will then reply to the wrong address. In this way, the third party can collect information that might be confidential. Note that this attack also violates the authentication requirement.

     Sniffing: Sniffers are programs that can read (and store) all TCP/IP packets sent on some LAN. Packages can then be displayed as plain text, filtered or handled in some other way. Sniffers are freely available on the Internet and can “easily” be installed from a semi-professional computer user. Installed on a laptop, a user just has to plug in into a LAN and can collect data sent on this LAN. Note that this attack poses also a problem on current log-on procedures since often passwords are also sent as plain text. If a sniffer reads a package that contains a password and the corresponding account name, that account can be freely used by some non-appropriate user.

 

The following section shortly explains consequences of these TCP/IP weaknesses for electronic mail applications and two ways to improve security of E-mail.

 

3.      Security of E-Mail

 

Since electronic mail is build directly on the TCP/IP protocol, it inherited all problems from this internet protocol. This especially means that a receiver of an E-mail can not be sure about the authenticity of the sender (remember IP spoofing). In addition, several mail server programs include a bug that makes it even simpler for anybody to send E-mail under arbitrary addresses. Moreover, E-mails are sent unencrypted in several TCP/IP packages such that secrecy is also not guaranteed. Therefore, one should be aware that one should never trust an E-mail that does not include some security enhancement.

 

Several protocols have been developed to increase the security of E-mail:

 

·         PEM (Privacy Enhanced Mail)[2]: PEM is an Internet Draft that provides security-related services for electronic mail applications. Its most common use is with the Simple Mail Transfer protocol (SMTP), but compatibility with other mail transport environment is supported. Cryptographic algorithms used by PEM are DES, Triple-DES, RSA and MD2/MD5.

 

·         PGP (Pretty Good Privacy) [3] or GNU Privacy Guard (GnuPG)[4]: Both programs implement the Open PGP standard[5]; their difference is the fact that GnuPG is part of the Open Source Project. They offer message encryption with both public key or secret key cryptosystems (for a list of currently supported algorithms, see the Open PGP description), digital signatures (an electronic equivalent to usual signatures), data compression, and compatibility with several mail transport environments. For some mail reading programs, easy-to-use plug-ins are available, such that confidentiality and authenticity of E-mails can be achieved in a simple way. Note that PGP/GnuPG is not restricted to E-mails (in contrast to PEM), but can also be used to encrypt or sign ordinary files.

 

The main difference between PEM and PGP is the handling of public key files. In public key cryptography, their exist two type of keys: publicly known keys that are used for encryption (so called public keys), and decryption keys that have to be kept secret[6] (secret keys). Public keys can easily be stored in a publicly accessible database. There is however a security problem if the integrity of public keys can not be ensured. Therefore public keys are usually stored together with so called certificates that certify that the keys are valid; these certificates are used to check the integrity of public keys. To ensure the integrity of certificates, there are “higher level” certificates for every certificate, and so on and so on. The key management structure of PEM is a centralized key authority agency that publishes certificates for public keys of sub-authorities; these sub-authorities publish certificates for public keys of sub-sub-authorities, and so on (a tree structure is usually used). PGP uses a different model of trust: a user trusts in the validness of some stored public key if he/she has “enough” certificates from friends whom he/she trusts. This “web of trust” is a highly decentralized concept, developed from the grass roots of the Internet community. For more details, I refer to the Open PGP specification.

 

 

4.      Secure Socket Layer (SSL)

 

Secure Socket Layer (SSL)[7] is a security protocol build on top of the Internet protocol TCP/IP. It was first announced and supported by Netscape. To overcome the security problems of TCP/IP, SSL offers authentication, secrecy using a secret key stream cipher, and supports electronic signatures. The focus of SSL is to overcome the security problems in TCP/IP that I described earlier. Therefore, it is especially often described as “fundamental part for securing electronic business applications”. From a theoretical point of the view, the protocol is generally considered to offer security, but in practice very often a few trap-doors are left open. SSL can be used for authentication between communication parties, but authentication is optional and per default not used. Thus, there remains the risk that most users are not aware that actually their transaction is done without authentication, a possible security risk. For authentication, public key certificates are needed. SSL supports the centralized concept of PEM. Certificates can already be bought at several private certification authorities. It is however questionable for me whether an “ordinary user” who wants to use electronic business once and a while is willing to spend money for buying a certificate. That means that user authentication might not be possible. However, business to business transaction are probably not influenced by this problem (an interesting research question would be a field study how many of the currently available e-commerce web sides actually have a valid certificate from a registered certification authority).

 

Another problem of SSL is the fact that due to US export restrictions (cryptography is still considered to be equivalent to weapons ¾ an attitude that seems to change slowly) there exist two versions of the SSL stream cipher algorithm:

 

·         The US version supports strong cryptography with 128 bit keys. The RC4 stream cipher with that key size is considered secure.

·         The International version supports weak cryptography with an effective key size of 40 bits only (i.e. 88 bits of the 128 bit key are publicly known). For such small key sizes, a brute force attack can be used to break the cryptosystem. This was practically proven in 1997 when researches could break an International-SSL message in about 8 days[8]. Due to increased processor speed, the time to break an international SSL message will decrease rapidly in future.

 

The latter problem is more a political than a science problem, since the US version of SSL is considered secure. It remains to hope that the US government will allow the usage of strong cryptography also for international versions of SSL. Otherwise there will always be a difference in the security of electronic commerce in different countries, or different protocols/standards have to be used in different countries. Both consequences are not favorable. As already mentioned beforehand, a user can not easily detect where a web side is located. Therefore, it is not immediately clear even to users located in the United States whether strong or weak encryption is used.

 

 

5. Conclusion

 

In this short note, I described security problems in two well-known Internet applications, electronic mail (E-mail) and web page access with SSL. Users should be aware that it is not always true that encryption automatically guarantees secrecy; only encryption with strong cryptosystems can give users this guarantee (see the SSL example). Since achieving trust in electronic business is complicated, many companies try to “convince” their customers with lots of technical information. In my opinion, cryptography experts have the responsibility to inform users as neutral and as clear as possible about existing security problems. In addition, users should have a healthy mistrust. Although many business people and politicians have great expectations in electronic business, warnings about possible security risks in electronic business should not be unheard by them ¾ it is better to know about the risks (and try to correct the problems) before an “accident” will make them obvious.

 

 

Epilog:

 

Today (3/27/2000) the Internet news service ZDnet (www.zdnet.com) published a news that a hacker succeeded in getting access to the credit card information of Bill Gates. He attacked nine E-commerce web sides and could break their security measures. In this attack, the hacker could copy confidential credit card information of about 20000 customers, stored at these sides.



[1] Menezes, van Oorschot, Vanstone: Handbook of Applied Cryptography, CRC Press, 1997.

[2] RFC 1421, RFC 1422, RFC 1423, RFC 1424, see http://www.faqs.org

[3] www.pgp.com

[4] www.gnupg.org

[5] RFC 2440, see http://www.faqs.org

 

[6] Menezes, van Oorschot, Vanstone: Handbook of Applied Cryptography, CRC Press, 1997.

[7] For specification of SSL V3.0, see http://home.netscape.com/eng/ssl3/index.html

[8] for the challenge http://www.portal.com/~hfinney/sslchal.html, for the solution http://para.inria.fr/~doligez/ssl/announce-rev.html