1

Table of contents Topics

Abstract 1. Introduction
1.1 History of internet security 1.2 General ways of providing security

Page No.

2. Background
2.1 Proxy Based Architecture 2.2 End-to-end Architecture

3 .SECURE SOCKETS LAYER (SSL)

3.1 Overview 3.2 Evolution of SSL

4. SSL working and description

4.1 SSL layers and working
4.1.1 SSL Handshake protocol 4.1.2 SSL Record protocol 4.1.3 SSL Change Cipher Spec Protocol 4.1.4 SSL Alert Protocol

4.2 SSL Encryption and Header

4.2.1 Encryption 4.2.2 Header

4.3 SSL Working

5. SSL Certificates and Practical Implementation

5.1 What is SSL and what are Certificates 5.1.1What is https 5.1.2 Concepts behind Certificates

6. TECHNOLOGY TRENDS 7. CONCLUSIONS AND FUTURE WORK 8. REFERENCES

ABSTRACT
Internet enabled wireless devices continue to proliferate and are expected to surpass traditional internet clients in the near future. This has opened up new opportunities in the mobile ecommerce market. However, data security and privacy remain major concerns in the current generation of wireless web offerings.

All such offerings today use a security architecture that lacks end-to-end security. This unfortunate choice is driven by perceived inadequacies of standard internet security protocols like SSL (Secure Socket Layer) on less capable CPUs and low bandwidth wireless links.

This seminar explains implementation and usage of standard security mechanism and protocols on small wireless devices. New classes for java 2 micro editions is created that offers fundamental cryptographic operations such as message digests and ciphers as well as higher level security protocols like SSL.

The seminar concludes that SSL is a practical solution for ensuring end-to-end security of wireless internet transactions even within todays technological constraints.

1. INTRODUCTION
In the past few years, there has been an explosive growth in the popularity and availability of small, handheld devices (mobile phones, PDAs, pagers), that can wirelessly connect to the Internet. These devices are predicted to soon outnumber traditional Internet hosts like PCs and workstations . With their convenient form factor and falling prices, these devices hold the promise of ubiquitous (anytime, anywhere) access to a wide array of interesting services. However, these battery driven devices are characterized by limited storage (volatile and nonvolatile memory), minimal computational capability, and screen sizes that vary from small to very small. These limitations make the task of creating secure, useful applications for these devices especially challenging. It is easy to imagine a world in which people rely on connected handheld devices not only to store their personal data, check news and weather reports, but also for more security sensitive applications like on-line banking, stock trading and shopping - mall while being mobile. Such transactions invariably require the exchange of private information like passwords, PINs and credit card numbers and ensuring their secure transport through the network becomes an important concern. On the wired Internet, Secure Sockets Layer (SSL) is the most widely used security protocol. Between its conception at Netscape in the mid-90s and standardization within the IETF in the late-90s, the protocol and its implementations have been subjected to careful scrutiny by some of the worlds foremost security experts. No wonder then, that SSL (in the form of HTTPS which is simply HTTP over SSL) is trusted to secure transactions for sensitive applications ranging from web banking to securities trading to e-commerce. One could easily argue that without SSL, there would be no e-commerce on the web today. Almost all web servers on the Internet support some version of SSL .Unfortunately; none of the popular wide-area wireless data services today offer this protocol on a handheld device. Driven by perceived inadequacies of SSL in a resource constrained environment, architects of both WAP and Palm.net chose a different (and incompatible) security protocol (e.g., WTLS for WAP) for their mobile clients and inserted a proxy/gateway in their architecture to perform protocol conversions. A WAP gateway, for instance, decrypts encrypted data sent by a WAP phone using WTLS and reencrypts it using SSL before forwarding it to the eventual destination server. The reverse process is used for traffic flowing in the opposite direction.

Such a proxy-based architecture has some serious drawbacks. The proxy is not only a potential performance bottleneck, but also represents a man-in-the-middle which is privy to all secure communications. This lack of end-to-end security is a serious deterrent for any organization thinking of extending a security-sensitive Internet-based service to wireless users. Banks and brokerage houses are uncomfortable with the notion that the security of their customers wireless transactions depends on the integrity of the proxy under the control of an untrusted third party .

We found it interesting that the architects of WAP and Palm.net made tacit assumptions about the unsuitability of standard Internet protocols (especially SSL) for mobile devices without citing any studies that would warrant such a conclusion. This prompted our experiments in evaluating standard security algorithms and protocols (considered too big by some) for small devices. We sought answers to some key questions: Is it possible to develop a usable implementation of SSL for a mobile device and thereby provide end-to-end security? How would near-term technology trends impact the conclusions of our investigation?

1.1 History of Internet Security

In 1987, the Vienna virus emerged. Ralph Burger got a copy of it, disassembled it, and published the result in his book Computer Viruses: a High-tech Disease. This particular book made the idea of writing viruses popular, explained how to do it, and resulted in creating up hundreds and in thousands of computer viruses implementing concepts from it. On November 2, 1988, Peter Yee at the NASA Ames Research Center sent a note out to the TCP/IP Internet mailing list that said, We are currently under attack from an Internet VIRUS! It has hit Berkeley, UC San Diego, Lawrence Livermore, Stanford, and NASA Ames. Of course, this report was the first evidence of what was to be later known as The Morris Worm. Roberts, a 23year-old Cornell University student, wrote some software code as part of a research project aimed at determining the size of the Internet. The worm was meant to infect computers, in order to see how many connections to the Internet existed. Because of a flaw in the software code, however, it ended up exploiting vulnerabilities in Unix and spread rapidly, infecting multiple machines multiple times and rendering them unusable.

5 In 1994, Russian hacker Vladimir Levin broke into Citibank's cash management system and embezzled $10 million into his own accounts. The stolen accounts were unencrypted and all but $400,000 of the stolen cash was recovered and Levin was arrested He pled guilty to conspiracy to commit computer, wire and bank fraud. On April 11, 1994, a full-scale epidemic broke out, caused by file and boot polymorphic virus called 'Tequila'. In September 1994, the same thing happened with the Amoeba virus. In 1996, the Boza virus emerged, which was the first virus designed specifically for Windows 95 files. In 1998, the first Java virus Strange Brew affected computers. In 2005, the Bropia Worm affected the Internet. It targeted MSN messenger for spreading. The 2007 Storm Worm was a Trojan horse. It included an executable file as an attachment. When the e-mail recipient opened the attachment, he or she unknowingly became part of a botnet (a collection of infected computers) to spread viruses and Spam. Once infected, a computer is called as a bot. It is an instance of adaptive malware. It has been used in different kinds of criminal activities. The authors and the controllers, of the Storm Worm, have not yet been identified.

1.2 General ways of providing security

The concept of cryptography helps a lot in the security prospect. There are a lot of Encryption methods (Algorithms) are also using such as RSA. Although these applications need the security: E-mail Encryption Web-site Encryption Application Encryption Remote user communication security by id and password Digital Signatures Using secure version of http (HTTPS) by SSL/TLS connection etc.

2. BACKGROUND
As wireless data services evolve, their architects are faced with two choices that can profoundly impact the future of the wireless Internet. They can adopt (if necessary, adapt) standard Internet protocols or create an entirely different set of standards applicable only in the wireless world. The former choice would seamlessly extend the Internet to future mobile devices; the latter could severely stunt its expansion. The Wireless Application Protocol (WAP) Forum subscribed to the wireless is different philosophy for its WAP 1.0 specification which defines an entire suite of protocols that parallel standard TCP/IP and web protocols, but are incompatible with them . In contrast, others like the IETFs PILC working group have put forth proposals to re-use existing protocols and standards in ways that accommodate the special characteristics of wireless networks without destroying compatibility.

2.1 Proxy Based Architecture

Due to protocol incompatibilities, a WAP device cannot communicate directly with the large installed base of Internet hosts. Instead, all communication must go through a gateway or proxy that performs protocol (and possibly content) translation. In typical deployments of WAP, this proxy is owned and maintained by a wireless service provider, who pre-programs the proxy in all of its customers phones. This allows the Service provider to control what parts of the Internet are accessible to its customers thereby creating a walled garden .

7 These architectural choices raise a number of concerns.

1. Scalability: Since a proxy must process data packets to and from a large number of mobile devices, it represents a potential performance bottleneck (besides being a single point of failure). The insertion of a proxy also precludes end-to-end flow control. Since the wired side of a proxy has greater bandwidth than its wireless side, the proxy needs to maintain large data buffers for each active data flow. 2. Legal: A recent French court ruling, prohibiting French Telecom from dictating which gateways its customers could use, is an indication that such an approach may have legal and anti-trust implications. 3. Security: The most glaring drawback of a proxied architecture is the lack of end-to-end security. In the process of decrypting and re-encrypting traffic, the proxy gets to see all communication in the clear3. This WAP gap problem is depicted in Figure 1 even though the wired and wireless hops are encrypted, the proxy is privy to all information exchanged. Sometimes the situation is even worse, as weak encryption (or none at all) is used on the wireless side giving mobile users a false sense of security.

This problem is not unique to WAP. The Palm.net security architecture uses a proprietary protocol based on Elliptic Curve Cryptography (ECC) between the wireless device and the Palm.net proxy (owned and operated by Palm). SSL is used only between the proxy and the eventual destination. Thus, when a Palm VII user accesses an HTTPS URL to establish a secure connection with a web-server, the connection that is set up isnt truly secure. This is unacceptable to security savvy organizations, e.g., Suns corporate firewall explicitly disallows connection attempts from the Palm.net proxy.

2.2 End-to-end Architecture

In contrast, the use of SSL between desktop PCs/workstations and Internet servers offers end to end security (Figure 2). This holds true even when an HTTPS proxy is used to traverse firewalls. Unlike the WAP or Palm.net proxy, an HTTPS proxy does not perform decryption/reencryption of data. Rather, it acts as a simple TCP relay shuttling encrypted bytes from one side to the other without modification. The expression old is gold is especially apt when considering security protocols. Very often, it takes years of widespread public review and multiple iterations to discover and correct subtle but fatal errors in the design and/or implementation of a security protocol. After more than five years of public scrutiny and deployment experience4, SSL is the most widely trusted security protocol for all sorts of web-based transactions. The addition of SSL capabilities to mobile devices would bring the same level of security to the wireless world.

3 SECURE SOCKETS LAYER (SSL)

3.1 Overview
SSL provides encryption, source authentication and integrity protection of application data over insecure, public networks. The protocol requires a reliable, bi-directional, byte-stream service. Typically, this service is provided by TCP which guarantees that there is no duplication, loss, or reordering of bytes.

As shown in Figure 3, SSL is a layered protocol. The Record layer sits above the underlying transport and provides bulk encryption and authentication services using symmetric key algorithms. The keys for these algorithms are established by the Handshake protocol which uses public-key algorithms to create a master secret between the SSL client and server. This master secret is further used to derive cipher keys, initialization vectors and MAC (Message Authentication Code) keys for use by the Record Layer. Until these keys are installed, the Record Layer acts as a simple bi-directional pass through for all data. Conceptually, the Alert protocol and the Change Cipher Spec protocol sits within the same layer as the Handshake protocol. The former is used for notification of any protocol failures. The latter is used to signal successful completion of the handshake and the start of bulk encryption and authentication in an SSL stream. SSL is very flexible and can accommodate a variety of algorithms for key agreement (RSA, DH, etc.), encryption (RC4, 3DES, etc.), and hashing (MD5, SHA, etc.). To guard against adverse interactions (from a security perspective) between arbitrary combinations of these algorithms, the standard specification explicitly lists combinations of these algorithms, called cipher-suites, with well-understood security properties.

10

The Handshake protocol is the most complex part of SSL with many possible variations . In the following subsection, we focus on its most popular form, which uses RSA key exchange and does not involve client-side authentication. The SSL protocol allows both client and server-side authentication. However, due to the unwieldy problem of maintaining client-side certificates, only the server is typically authenticated. Client authentication, in such cases, happens at the application layer above SSL, e.g., through the use of passwords (one-time or otherwise) sent over an SSL-protected channel. The servers Certificate Request message, as well as the client shutdown Certificate and Certificate Verify messages shown in Figure 4, are only needed for client-side authentication and rarely encountered in practice. Secure Socket Layer (SSL) denotes the predominant security protocol of the Internet for World Wide Web (WWW) services relating to electronic commerce or home banking. The majority of web servers and browsers support SSL as the de-facto standard for secure clientserver communication. The Secure Socket Layer protocol builds up point-to-point connections that allow private and unimpaired message exchange between strongly authenticated parties. In the ISO/OSI reference model [ISO7498], SSL resides in the session layer between the transport layer (4) and the application layer (7); with respect to the Internet family of protocols this corresponds to the range between TCP/IP and application protocols such as HTTP, FTP, Telnet, etc. SSL provides no intrinsic synchronization mechanism; it relies on the data link layer below. The SSL protocol allows mutual authentication between a client and server and the establishment of an authenticated and encrypted connection. SSL runs above TCP/IP and below HTTP, LDAP, IMAP, NNTP, and other high-level network protocols.

11

In general:
SSL Secure Socket Layer It provides a secure transport connection between applications (e.g., a web server and a browser), SSL was developed by Netscape, V2 1994 netscape V3 1996 netscape SSL version 3.0 has been implemented in many web browsers (e.g., Netscape Navigator and MS Internet Explorer) and web servers and widely used on the Internet. A protocol widely used on the Web Operates between the application and transport layers.

HTTP, FTP,SMTP SSL TCP IP Data Link Physical

Figure 4: Layer architecture Operations of SSL Negotiation for PKI Server and browser negotiate to select cryptographic algorithm and create a session secret key. Communications. Encrypted by using the key that was negotiated.

12

Figure 5: Example of remote server and web browser

3.2 Evolution of SSL?

Netscape developed the first specification of SSL in 1994, but only publicly released and deployed the next version, SSLv2, in the same year [SSL2]. With respect to public key Cryptography, it relies mainly on RSA encryption (RSA cryptosystem) and X.509-Compliant certificates. Block ciphers, such as DES, Triple DES (3DES), and RC4, along with hash functions like MD5 and SHA, complement the suite of algorithms. SSLv3 followed in 1995, adding cryptographic methods such as Diffie-Hellman key agreement (DH), support for the FORTEZZA key token, and the Digital Signature Standard (DSS) scheme [SSL3]. The most recent draft of the SSL 3.0 specification was published in November of 1996 by Netscape. The intent was to be a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The goals included cryptographic security, interoperability, extensibility, and relative efficiency. Interoperability was a goal so that applications could be written to the standard and expected to work with any other applications written to the standard. Interoperability, it was noted, does not imply that two programs will always be able to connect. One might not have the correct algorithm support or credentials necessary for the connection to the other.

13 Extensibility was described as providing a framework into which new public key and bulk encryption methods can be incorporated as necessary. It was noted that this should prevent the need to implement a new security protocol entirely should a weakness be found in one of the current encryption methods. Cryptography, obviously, causes a higher CPU load than sending the data unencrypted. Still, they made some effort to minimize the network traffic and allow for session caching.

3.2.1 SSL v2.0

Released by Netscape Communications in 1994. The main goal of this protocol was to provide security for transactions over the World Wide Web. Unfortunately, very quickly a number of security weaknesses were found in this initial version of the SSL protocol, thus making it less reliable for commercial use:
o o o

weak MAC construction possibility of forcing parties to use weaker encryption no protection for handshakes

Possibility of an attacker performing truncation attacks.

3.2.2 PCT v1.0

Developed in 1995 by Microsoft. Privacy Communication Technology (PCT) v1.0 addressed some weaknesses of SSL v2.0, and was aimed to replace SSL. However, this protocol has never gained as much popularity as SSL v3.0.

3.2.3 SSL v3.0

Released in 1996 by Netscape Communications. SSL v3.0 solved most of the SSL v2.0 problems, and incorporated many of the features of PCT. Pretty quickly become the most popular protocol for securing communication over WWW.

14

Figure 6: SSL Record Layer

15

4 .SSL working and description

4.1 SSL layers and working?

SSL splits into distinct layers and message types.SSL/TLS has 4 underlying protocols: Handshake, Record, Change Cipher Spec, and Alert. The working of these layers as follows:-

4.1.1 SSL Handshake protocol:The handshake message sequence initiates the communication, establishes a set of common parameters like the protocol version, applicable cryptographic algorithms (cipher suites), and assures the validity of the message sequence. During the handshake, the participants accomplish the negotiated authentication and derive the session key material. In this way Handshake protocol does : Negotiation of security algorithms and parameters, Key exchange, Server authentication and optionally client authentication.

TLS connections begin with a 6-way handshake. The handshake protocol structure is:

Figure 7 The handshake protocol structure is

The allowed values for type are as follows: 0 HelloRequest 1 ClientHello 2 ServerHello

16 11 Certificate 12 ServerKeyExchange 13 CertificateRequest 14 ServerHelloDone 15 CertificateVerify 16 ClientKeyExchange 20 Finished

4.1.2 SSL Record protocol:The record layer fragments the full data stream into records with a maximum size of 214 bytes and envelopes them cryptographically under the current session keys. Records contain a keyed message authentication code (HMAC). The initial handshake presupposes a NULL cipher suite applying no encryption and no HMAC. The record layer fully provides the use of compression. However, for patent reasons the core specifications name no method explicitly, except for the mandatory NULL algorithm, which practically makes compression an incompatible, implementation-dependent feature.

The basic layer structure and message is as follows: In this way the Record protocol does: Fragmentation, Compression, Message authentication and integrity protection, Encryption.

4.1.3 SSL Change Cipher Spec Protocol:It is a single message that indicates the end of the SSL handshake. The change cipher can understood as follows:

17

Figure 8 State Changes Operating state Currently used state. Pending state State to be used, built using the current state.

4.1.4 SSL Alert Protocol:Alert messages inform on exceptional protocol conditions (fatal alerts and warnings) or on a participants request to end the communication (closure alert). Each alert message consists of 2 fields (bytes) 1. first field (byte): warning or fatal 2. second field (byte): fatal unexpected_message bad_record_MAC decompression_failure handshake_failure illegal_parameter warning

18 close_notify no_certificate bad_certificate unsupported_certificate certificate_revoked certificate_expired certificate_unknown In case of a fatal alert connection is terminated, session ID is invalidated, no new connection can be established within this session.

4.2 SSL Encryption and Header?

SSL can use following Encryption and Header types:-

4.2.1 Encryption:It supports following algorithms: block ciphers (in CBC mode) RC2_40 DES_40 DES_56 3DES_168 IDEA_128 Fortezza_80 stream ciphers RC4_40 RC4_128 If a block cipher is used, than padding is applied, last byte of the padding is the padding length.

4.2.2 Header:It supports following header types: change_cipher_spec

19 alert handshake application_data The higher level protocol used to process the enclosed fragment. Length (in bytes) of the enclosed fragment or compressed fragment max value is 214+ 2048.

4.3 SSL Working?

The working of SSL can be show as following:The SSL handshake accomplishes three goals. Firstly, both parties agree on a cipher suite, i.e. the set of cryptographic algorithms that they intend to use for application data protection. Secondly, they establish a common master_ secret in order to derive their session key material. Thirdly, the participants identities are authenticated. Although the SSL specification permits anonymous, server-only and mutual authentication, it is customary to only assert the servers identity. This Figure gives an overview of the SSL protocol variants. It comprises four different handshake sequences, each identified by a capital letter: S,C,E,R which denotes: S denotes the server-authenticated message flow. C marks the sequence with additional client authentication. E shows the handshake variant with ephemeral Diffie-Hellman key agreement. R stands for the handshake of resumed sessions. Note, that the message pairs.

ChangeCipherSpec / Finished of client and server are drawn in reverse order; the server message pair follows ServerHello immediately.

Process:First the client sends the Client Hello message which includes a 32-bit Unix format timestamp and a 28-byte random number. The client may also specify a session identifier of a current or previous session. Doing this allows for multiple secure connections without going through the entire handshake process each time, although both Hello, the Change Cipher Spec, and both Finished messages must still be exchanged and be valid.

20

Figure 9 SSL Protocol Sequence

The client then includes a list of acceptable Cipher Suites and Compression Methods. Each cipher suite defines the algorithm for key exchange, the bulk encryption algorithm with secret key and length, and the message authentication code (MAC). The server then responds to this with the Server Hello message. The server hello message will have the following data: The version number being used: the lower of the servers highest

supported version and the version in the client hello. A random number generated by the server.

21 The session identifier: if the Session ID is recognized, then a short

handshake is used and the following fields are filled in with the values from the previous connection. Otherwise, the Server Hello generates a new Session ID. The cipher suite chosen by the server, and The compression method chosen by the server.

If the server cannot find an acceptable cipher suite and compression method, it will respond with a handshake failure alert. Unless the key exchange method is anonymous, the server will send out a Certificate immediately after sending the Server Hello. The certificate is generally a X.509v3 certificate public key and unless otherwise specified uses the same key exchange method and signing algorithm previously decided on. After the servers certificate, certificates from all the up line servers necessary to get to one that the client trusts must be included. The order of these should be such that each certificate validates the one before it. If the server Certificate does not contain enough data for a premaster secret, then a Server Key Exchange is sent with either a RSA public, or a Diffie-Hellman public key. (This is the case for DHE_DSS, DHE_RSA, and DH_anon; but not for RSA, DH_DSS, and DH_RSA key exchange methods.) If it is appropriate, the server may request a certificate from the client with a Certificate Request. This would immediately follow the Server Certificate, or if present the Server Key Exchange. The Certificate request would specify the types of certificates the server will accept and the Certificate Authorities the server trusts. The client, after receiving the Server Hello Done would respond with a message identical in format to the Server Certificate. The Server Hello Done indicates to the client that server is done sending data and the client should now verify the certificates and whatnot it has received. If a Certificate Request was received, the client would now send the Certificate.

If RSA is used, the Client Key Exchange message includes an encrypted pre-master secret which consists of a 48-bit number that is encrypted with the servers public key.If Diffie-Hellman is used, but not Fixed Diffie-Hellman, then the public key parameters are sent here.

22 If the client sent a certificate, then it would send a Certificate Verify message hat this point, in most cases. This would include a signature in the same format as defined for the Server Key Message as well as an md5 sum of all of the previous messages and a SHA hash of all of the previous messages.

The Client sends the Change Cipher Spec message indicating that all future traffic will be computed with the Master Secret. The random numbers and the pre master secret are used by both systems in a pseudorandom function to calculate the master secret. The change cipher spec protocol is a single byte that will always have a value of 1. It is encrypted and compressed under the current cipher (the pre master secret) and compression method. The client now sends the Finished Message. This consists of the master secret, the finished label, an md5 of all previous messages and an SHA of all previous messages. All of this is encrypted with the master secret. If the server can read all of this, then the server knows that the key generation was successful. The server responds with its own Change Cipher Spec and Finished messages which verify to the client that the key generation was successful. If any warning or fatal errors occur, an alert is sent. Alerts consist of a byte that defines whether its a warning (1) or a fatal (2) alert, and a byte that indicates the specific alert. When the master secret is computed, data may be sent encapsulated inside of record protocol. This data will be encrypted and compressed in the agreed upon methods and can be reliably read by the other end but not likely anyone in-between.

23

5. SSL Certificates and Practical Implementation

5.1 What is SSL and what are Certificates?

The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works. 1. A browser requests a secure page (usually https://). 2. The web server sends its public key with its certificate. 3. The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted. 4. The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data. 5. The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data. 6. The web server sends back the requested html document and http data encrypted with the symmetric key. 7. The browser decrypts the http data and html document using the symmetric key and displays the information.

5.1.1 What is https?

Hyper Text Transfer Protocol Secure (HTTPS) is a secure version of the Hyper Text Transfer Protocol (http). HTTPS allows secure ecommerce transactions, such as online banking. Web browsers such as Internet Explorer and Firefox display a padlock icon to indicate that the website is secure, as it also displays https:// in the address bar. When a user connects to a website via HTTPS, the website encrypts the session with a digital certificate. A user can tell if they are connected to a secure website if the website URL begins with https:// instead of http://.

24 HTTPS is effectively HTTP using SSL (Secure Sockets Layer). SSL merely encrypts the content of the packets before being sent from the server to client.

5.1.2 Concepts behind Certificates?

Following concepts are used in identification and validation of SSL certificates:-

5.1.2.1 Private Key/Public Key:

The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. This is sometime hard to understand, but believe me it works. The keys are similar in nature and can be used alternatively: what one key emcrypts, the other key pair can decrypt. The key pair is based on prime numbers and their length in terms of bits ensures the difficulty of being able to decrypt the message without the key pairs. The trick in a key pair is to keep one key secret (the private key) and to distribute the other key (the public key) to everybody. Anybody can send you an encrypted message, that only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite , you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. Beware, in this case the message is not secured you have only signed it. Everybody has the public key, remember! One of the problem left is to know the public key of your correspondent. Usually you will ask him to send you a non confidential signed message that will contains his public key as well as a certificate. Message-->[Public >Message Key]-->Encrypted Message-->[Private Key]--

5.1.2.2 The Certificate:

A SSL certificate does following tasks:1. An SSL Certificate enables encryption of sensitive information during online transactions.

25 2. Each SSL Certificate contains unique, authenticated information about the certificate owner. 3. A Certificate Authority verifies the identity of the certificate owner when it is issued.

5.1.2.2.1 Who need SSL certificate ?

SSL should be used by any organization wishing to:

Secure online credit card transactions Secure online system logins, web forms, web mail, control panels or protected areas of web sites

Secure the transfer of files over https and FTP services such as web site owners updating new pages to their web sites

Secure the connection between an email client such as Microsoft Outlook and an email server such as Microsoft Exchange

Secure intranet basedtraffic such as intranets, extranets and database connections

The e-commerce business is all about making money and then finding ways to make more money. Of course, it's hard to make (more) money, when consumers don't feel safe executing a transaction on your Web site. That's where SSL (Secure Socket Layer) comes into play.

5.1.2.2.2 Working of certificate?

SSL is all about encryption. SSL encrypts data, like credit cards numbers (as well other personally identifiable information), which prevents the "bad guys" from stealing your information for malicious intent. You know that you're on an SSL protected page when the address begins with "https" and there is a padlock icon at the bottom of the page (and in the Mozilla Firefox in the address bar as well).

The browser encrypts the data and sends to the receiving Web site using either 40-bit or 128-bit encryption. Your browser alone cannot secure the whole transaction and that's why it's

26 incumbent upon e-commerce site builders to do their part.

SSL certificates come in 40-bit and 128-bit varieties, though 40-bit encryption has been hacked. As such, you definitely should be looking at getting a 128-bit certificate.

Though there a wide variety of ways in which you could potentially acquire a 128-bit certificate, there is one key element that is often overlooked in order for full two-way 128-bit encryption to occur. According to SSL certificate vendor VeriSign, in order to have 128-bit encryption you need a certificate that has SGC (server grade cryptography) capabilities.

How Encryption Works:Imagine sending mail through the postal system in a clear envelope. Anyone with access to it can see the data. If it looks valuable, they might take it or change it. An SSL Certificate establishes a private communication channel enabling encryption of the data during transmission. Encryption scrambles the data, essentially creating an envelope for message privacy. Each SSL Certificate consists of a public key and a private key. The public key is used to encrypt information and the private key is used to decipher it. When a Web browser points to a secured domain, a Secure Sockets Layer handshake authenticates the server (Web site) and the client (Web browser). An encryption method is established with a unique session key and secure transmission can begin. True 128-bit SSL Certificates enable every site visitor to experience the strongest SSL encryption available to them.

How Authentication Works:Imagine receiving an envelope with no return address and a form asking for your bank account number. Every VeriSign SSL Certificate is created for a particular server in a specific domain for a verified business entity. When the SSL handshake occurs, the browser requires authentication information from the server. By clicking the closed padlock in the browser window or certain SSL trust marks (such as the VeriSign Secured Seal), the Web site visitor sees the authenticated organization name. In high-security browsers, the authenticated organization name is prominently displayed and the address bar turns green when an Extended Validation SSL Certificate is detected. If the information does not match or the certificate has expired, the browser displays an error message or warning.

27

Why Authentication Matters:Like a passport or a drivers license, an SSL Certificate is issued by a trusted source, known as the Certificate Authority (CA). Many CAs simply verify the domain name and issue the certificate. VeriSign verifies the existence of your business, the ownership of your domain name, and your authority to apply for the certificate, a higher standard of authentication. VeriSign Extended Validation (EV) SSL Certificates meet the highest standard in the Internet security industry for Web site authentication as required by CA/Browser Forum. EV SSL Certificates give high-security Web browsers information to clearly display a Web sites organizational identity. The high-security Web browsers address bar turns green and reveals the name of the organization that owns the SSL Certificate and the SSL Certificate Authority that issued it. Because VeriSign is the most recognized name in online security, VeriSign SSL Certificates with Extended Validation will give Web site visitors an easy and reliable way to establish trust online.

5.1.2.2.3 Who can issue SSL Certificates?:

SSL Certificates can be issued by anybody using freely available software such as Open SSL or Microsoft's Certificate Services manager. Such SSL Certificates are known as "self-signed" Certificates. However, self-signed SSL Certificates are not inherently trusted by customer's browsers and whilst they can still be used for encryption they will cause browsers to display "warning messages" - informing the user that the Certificate has not been issued by an entity the user has chosen to trust. Such warnings are undesirable for commercial sites - they will drive away customers. In order to avoid such warnings the SSL Certificate must be issued by a "trusted certifying authority" trusted third party Certification Authorities that utilize their trusted position to make available "trusted" SSL Certificates.

28

6. TECHNOLOGY TRENDS
Since starting this project about an year ago, weve seen several examples of technologys relentless march towards smaller, faster and more capable devices. Newer Palm PDAs like the PalmVx and PalmIIIc use 20MHz processors and the Handspring Visor Platinum (another PalmOS device) features a 33MHz processor, both considerable improvements over the earlier 16MHz CPUs. All of them offer 8MB of memory. The Compaq iPaQ pocket PC , in comparison, carries a 200MHz StrongARM processor and 16-32MB of memory. The CPU enhancements have a direct impact on the speed of SSLs cryptographic operations. Significant performance gains are also obtainable by using hardware accelerators in the form of tiny smart cards (and related devices like the iButton). The Schlumberger Cyberflex smart card, for instance, can perform 024-bit RSA operations (both public- and private-key) in under one second.

Similarly, improvements can also be seen in the speed of wireless networks. Metricoms Ricochet service now offers wireless data speeds of 128Kbits/s in several U.S. cities and 3G networks hold the promise of even faster communication in the next year or two. These improvements help reduce the network-related latency of an SSL handshake. Even with the older 32Kbits/shutdown Ricochet service, we see 1520Powerful handhelds like the iPaQ using 802.11 for wireless connectivity have no problems whatsoever running SSL.

Even smart compilation techniques, which had so far been available only on more capable PCs and workstations, are now available on small devices and can boost the performance of J2ME applications by as much as a factor of five . These developments should alleviate any remaining concerns about SSLs suitability for wireless devices. They also highlight an interesting phenomenon: In the time it takes to develop and deploy new (incompatible) protocols, technology constraints can change enough to

29

raise serious questions about their long-term relevance. The following quote captures this sentiment rather well: Dont skate to the puck; skate to where its going. Wayne Gretzsky (Ice HockeyLegend) In light of this view, it is reassuring to see the WAP Forum embracing standard IETF and W3C protocols for its next (WAP 2.0) specification.

30

7. CONCLUSIONS AND FUTURE WORK

The experiments show that SSL is a viable technology even for todays mobile devices and wireless networks. By carefully selecting and implementing a subset of the protocols many features, it is possible to ensure acceptable performance and compatibility with a large installed base of secure web servers while maintaining a small memory footprint.

The implementation brings mainstream security mechanisms, trusted on the wired internet, to wireless devices for the first time. The use of standard SSL ensures end-to-end security, an important feature missing from current wireless architectures. The latest version of J2ME MIDP incorporating KSSL can be downloaded from.

31

8. REFERENCES
[1] IDC, IDC Envisions a Time When Majority of Internet Access Will Be Through wireless Devices, see http://www.idc.com:8080/communications/press/pr/CM0 41000pr.stm [2] [3] Certicoms Secure Memopad Application, see http://www.palmgear.com/software Frier, A., Karlton, P., Kocher, P., The SSL3.0 Protocol Version 3.0, see http://home.netscape.com/eng/ssl3/ [4] Dierks, T., Allen, C., The TLS Protocol Version 1.0 see http://www.ietf.org/rfc/rfc2246.txt [5] Wagner, D. and Schneier, B., Analysis of the SSL 3.0 protocol, 2nd USEN IX Workshop on Electronic Commerce, 1996. Available from http://www.cs.berk ley.edu/daw/papers/. [6] Murray, E., SSL Server Security Survey, see http://www.lne.com/ericm/papers/ssl server stats.html [7] The Wireless Application Protocol Forum, see http://www.wapforum.org/