Securing Clientserver Transactions Securing Clien

/Server Transactions The three basic ways that security is implemented in the area of client/server transaction. The first area is firewalls. The basic idea of a firewall to monitor traffic from a trusted network ( a companyЎЇs internal network) to an untrusted network (such as the Internet). Firewalls fall into two categories, ÐŽoproxiesÐŽ± and ÐŽopacket-filteringÐŽ± firewalls. Packet-filtering determines whether a packet is allowed or disallowed depending on the source of the packet and the contents of it. Packet-filtering also looks at the source and destination ports, and to determine if a packet is part of an ongoing conversation. An application-level firewall, better known as a proxy acts as an intermediary between the client and the server. The client application connects to the proxy. The proxy opens a connection to the server and passes information back and forth between the server and the client (refer to Figure 1.). Figure 1. Both firewalls have their advantages and disadvantages. In most cases both categories will be implemented on the same firewall. A packet-filtering firewall tends to be less secure than a proxy based firewall, since complete knowledge of the protocol is used by the application. However packet filtering can allow a concept known as masquerading. Masquerading is when the firewall takes the outgoing source address on the packets and converts the address so the receiver thinks they are talking to the firewall. The receiverЎЇs packets will have itЎЇs address on it coming back so the firewall can determine which sender gets the packet. The advantage of masquerading is that a companyЎЇs internal network can be hidden behind the firewall. Another security implementation is encryption. Encryption is the process of modifying information so that it can not be read by anyone except the intended recipient. This is done by applying mathematical algorithms that require a ÐŽokeyÐŽ± to unlock, or decrypt, the original data. Algorithms that use the same key to encrypt and decrypt data are known as ÐŽosymmetricÐŽ± encryption algorithms. Algorithms that use different keys to encrypt and decrypt data are known as ÐŽoasymmetricÐŽ± or ÐŽopublic-keyÐŽ± encryption algorithms. Encrypted data comes in two forms 40-bit and 128-bit. 40-bit encryption uses a 40 bits of space to encrypt data and 128 bits of space for the 128-bit form. The process of verifying the senderЎЇs identity is known as ÐŽoauthenticationÐŽ±. Authentication can be performed with a user name and password, or with a piece of information known as a ÐŽodigital certificateÐŽ±. A digital certificate contains encryption parameters, which can be used to uniquely identify a user or a host system. Verifying that an external party has not modified data is known as ÐŽointegrity checkingÐŽ±. Integrity checking is done by applying a mathematical algorithm, known as a ÐŽohashÐŽ±, to data before itЎЇs sent and computing the same hash when the data is received. If the two hashes map to the same result, then the data hasnЎЇt been modified. How do these areas affect client/server transaction? Client/server transaction deals with the everyday transactions that people engage in on the Internet. With each transaction, personal information is sent from client to vendor. The information has a tendency to be sensitive in nature and not something shared with anyone except the vendor. Such information may include social security numbers, credit card numbers, and possibly information for monthly bills (account numbers and balances specifically). Businesses have to save-guard their customers in order for their customers to feel secure in buying products and services from them. Businesses understand this importance. Some businesses and development groups have evolved from the need to make business transactions more secure on the Internet. In doing so, business presence has grown exponentially over the last decade. Commercials on TV tell business owners if they arenЎЇt on the web, they wonЎЇt survive. Programmers face difficult and exciting challenges in the areas of security for client/server transaction. One of the most popular languages used on the Internet is Java. Java runs on many different platforms, which makes it very versatile in Internet applications. JavaSoftTM has introduced the Java Commerce Client (JCC) framework. The JCC provides a secure, robust, and reliable platform that enables software vendors to write electronic commerce applications. With a framework, you focus on the application-specific business logic and let the framework handle the low-level programming details. Application-specific code is organized into modules called cassettes. A cassette represents one part (or module) of a transaction. Cassettes are mixed and matched to lay the foundation for an electronic transaction. A cassette designed by one vendor can interact with one or more cassettes by that same vendor or by agreement with a cassette from another vendor. The JCC framework orchestrates cassette interoperations and enforces the high level of security required for reliable transactions between clients and merchant servers. The framework and cassette innovation supports a full range of large and small money-based applications such as personal finance software, tax calculation programs, and retail sales applications--all of which can run on any Java-enabled platform with the JCC framework installed. The JCC framework consists of commerce-related classes, interfaces, and cassettes for you to implement your own application-specific electronic commerce code, and an environment within which the application code runs. Clients with an installed and configured JCC framework can initiate transactions on a commerce server that execute on the client machine. The JCC framework enables the cassette interoperations that form a transaction. A cassette is a signed Java ARchive (JAR) file containing the compiled classes that implement one part of an electronic commerce transaction on the client side. One transaction typically involves several interoperating cassettes. Cassette functionality is defined primarily by the code in a commerce Bean. There are several types of commerce Beans, but the following three types that provide the basic functionality for a purchase transaction: ?An operation Bean to implement an action such as a purchase. ?A protocol Bean to implement the electronic transfer standard to use. ?An instrument Bean to implement the form of payment such as VISA. An electronic purchase transaction requires a purchase operation cassette, one or more protocol cassettes, and one or more instrument cassettes. Note that a commerce Bean is similar to but not exactly like a standard JavaBean. Commerce Beans are not currently written to the same specifications as JavaBeans, and support additional security and other functions required by the