It is an accepted fact that we are moving ever more rapidly from an analogue to a digital world. Every household item contains a computer, we listen to digitally mastered music, we need a degree in computer science (or alternatively an eight year old child) to program our video recorders, and the age of electronic commerce beckons.

This same trend is also evident in the business environment, of course. A recently published report from O�Reilly Research (Tel. 01264 342988) entitled "The State of Web Commerce", indicates that electronic commerce is among the most significant motivators driving businesses to the Internet. Of 1,038 businesses interviewed:

• 69% identified Internet-based customer support as critically important or significant
• 68% identified marketing in the same way
• 57% cited selling products as their key goal
• 60% think the Internet represents a new and important channel
• 51% believe that strategic use of the Internet will increase revenue

Unfortunately, in the last couple of years we have seen a great deal of press coverage devoted to Internet security � or rather the lack of it. This makes people wary of losses through electronic crime and credit card fraud, resulting in confusion and worry for those businesses who would otherwise be interested in, and reap a huge benefit from, the adoption of electronic commerce.

It is important to put these things into perspective, however. There have always been impediments to business, whether it be highwaymen, shipwrecks, pirates, bank robbers, or white-collar fraudsters. Each new innovation brings a new risk, yet whatever the risk, the business community must learn to adapt, minimise and, at worst, insure against, that risk.

At the end of the day, moving the platform from a traditional shop front to the electronic shop front of the Internet does not significantly increase or decrease the overall risk � we simply get a new breed of pirate.

What exactly is electronic commerce? Most companies which have dipped a toe into the water have so far restricted their on-line activities to electronic advertising and marketing. Users can browse on-line catalogues and other product literature, perhaps even placing an order via the Internet. But when it comes to paying for those goods and services, traditional methods of payment via telephone � usually with credit cards � is used.

Going forward, however, it is inevitable that both customer and vendor will want to move towards a completely electronic transaction, involving placing the order for goods or services, providing customer information and arranging or performing payment.

This brings the customer into the world of the "virtual shopping mall". Much has been written about the social implications of such an innovation, with the most popular tabloid image that of the sad, lonely individual who never ventures from his home and cannot interact with his fellow man. Whilst there is an element of truth in such an observation, such cases will be few and far between. Instead, we are likely to see huge advantages for the majority of our society.

Like it or not, we work more hours today than we ever did (what happened to the dream of technology actually reducing our workload and increasing our leisure hours?). We don�t want to spend our precious spare time trailing round Sainsburys for our mundane weekly shop. Parents with young children do not want to have to get them ready, wrestle them into the car and haul them screaming from their squeaky trolly all around the aisles of Tescos just to acquire a bumper pack of disposable nappies and a box of paracetamol.

Instead, we want to be able to acquire such everyday items electronically. We want to be able to create our "virtual shopping basket" of regular weekly items which is stored on-line, added to or subtracted from as required, and paid for via our PC, to be delivered the next day to our door. Far from reducing the quality of our lives, this automates the mundane tasks, leaving us free to concentrate on our leisure activities, or more "productive" shopping expeditions. Because, of course, at the end of the day, people will still go shopping. We cannot resist trying on the clothes, testing the swing of those golf clubs, getting behind the wheel of that new car, or simply scanning the contents of those books we have been meaning to buy. But by shopping for the ordinary, everyday or difficult to find items over the Internet, the shopping trip of the future can be more of a pleasure than a chore.

Of course, there remains the barrier of security, as we have already mentioned. In a face-to-face transaction, it is very difficult to "fake it". The legitimacy of a major department store is easy to verify � it is huge, it has all the right livery, it contains expensive displays and stock items, and is staffed by real people wearing name tags and corporate uniforms. In addition, the entire transaction is within our view and under our control � we can see the goods we are about to buy, perhaps try them out in the store, we hand over our cash or credit card and can verify that the sales assistant is processing the sale correctly. Things are not quite so straightforward on the Internet. With enough resources thrown behind a Web presence, even the smallest one-man band can appear as grand as Harrods. How, then do customers know they are dealing with legitimate businesses?

And how does the business know it is dealing with a legitimate customer? This is a problem in the "real" world too, of course, as the figures for credit card fraud demonstrate quite adequately. However, in a face-to-face transaction, the shop assistant can attempt to assess the appearance of a customer, judge the body language, watch the fluency of the signature, and match the signature to that on the card with reasonable care and accuracy. The opportunity for fraud is greatly increased when the potential fraudster can hide behind a PC, from where fake payment or personal details can be provided easily.

Privacy is another issue. When purchasing from a store, we can remain fairly anonymous by paying for an item with cash, but this can never be an option with electronic commerce. To date in our dealings on the Internet too, we have been able to hide behind aliases and anonymous postings in order to conceal our true identity where required. Indeed, the Internet depends on that feature in order to maintain the level of outspokenness which is its trademark, and which is surely worth preserving.

In stark contrast, however, the whole issue of security revolves around the ability to prove beyond a shadow of a doubt that we are who we say we are, and that we have the means to pay for the goods we are ordering. Without the ability to verify the identity of a potential customer, the Internet will never realise its potential as a universal backbone of commerce and communications. After all, neither merchant nor customer is likely to feel comfortable exposing himself to the electronic equivalent of the guy wearing a pair of tights over his head!

This requires that we provide a number of personal details � at the very least or name and address � together with some sort of unique ID (which can range from a simple password or PIN number to an elaborate smart card or biometric readout) in order to provide concrete proof of our identity. Once the vendor has these details, of course, it is fair to assume that there will be a degree of manipulation in the name of marketing � perhaps storing our shopping habits and preferences in some gigantic database. The customer thus needs to be sure that such personal details will be stored securely, and not made available to third parties without prior written consent.

Finally, if all else fails there is the legal angle. Assuming that some form of fraud or inappropriate disclosure of personal details has taken place during an electronic transaction, what are the indemnifying factors that protect both merchant and customer? The non-computerised trading world has never been 100 per cent secure, and most people understand the sort of protection they can expect when using a credit card � if someone makes off with your card, the issuer makes good on its promise to protect both you and the merchant.

Of course, the card companies know that they have to write off four or five per cent of their profits to fraud, but this level of write-off is perfectly acceptable given the increase in business they get by allowing customers to use their cards with impunity. This relationship is why the whole system works as well as it does, and it needs to be mirrored on the Web.

It is unlikely that electronic commerce will enjoy wide market acceptance unless the extent of end-user liability is clearly understood by both parties. The hit taken by the card issuers for fraud is likely to be even higher, but then so are the potential gains from a whole new market.

But we are getting ahead of ourselves here � already talking about the inevitability of fraud when we really need to be discussing how we can prevent it from happening. At the end of the day, consumer confidence is the key to the success of the electronic marketplace, and this confidence is born of two things. The first is the guaranteed indemnity of which we have already spoken, and the second is the assumption that the system is inherently secure.

As customers, we all know that banks can be held up, but we are equally confident that such an event is an extremely rare occurrence. So we need to be sure that the systems behind the Internet bank and the electronic mall are also resistant to all but the most determined attack � the equivalent of half a dozen guys in ski masks with guns, a few pounds of plastic explosive and a couple of fast getaway cars. No system can ever be 100 per cent secure, but it has to be secure enough to deter the casual hacker � we don�t want some spotty adolescent spiriting away our hard earned dosh from his bedroom using nothing more than a cheap PC, a modem and a few lines of code he downloaded from the "Hackers �R� Us" Web site.

Traditional EDI (Electronic Data Exchange) applications assume that the parties transmitting data are already well known to each other, or that the data is being transmitted over a secure channel or network (often a private link). This assumption does not work when dealing over the Internet, where there are literally millions of users, with identities being added, changed and deleted all the time. It is also quite obviously unwise to assume that the Internet is a secure channel that is tamper-proof. A different approach is therefore required.

The first step in protecting our on-line transactions is to ensure that the information remains hidden from anyone for whom it is not intended. Encryption offers this level of privacy, transforming plain text into a form unreadable by anyone without a secret decryption key, allowing secure communication over a general purpose insecure channel, such as the Internet.

Although the mathematics behind it can be very complex, encryption itself is pretty straightforward. Cast your minds back to when you were kids and you wanted to send secret messages to each other. The simplest form of encryption was the one where every letter of the alphabet was substituted for the one "n" positions following it.

Here we are introduced fairly painlessly to the two most important buzzwords in the cryptography world: the "key" is the number of positions we are shifting the letters, whilst the "algorithm" is simply the idea that the encrypted letter is the one "n" places following the plaint text letter.

There are two ways you can beef up security on this � increase the length of the key, and devise ever more complex algorithms. Luckily, we do not have to get involved in creating our own algorithms, since there are some perfectly acceptable standards out there, the main ones being DES (Data Encryption Standard), triple DES, IDEA (International Data Encryption Algorithm) and RC4. Whereas the original DES algorithm uses 56 bit keys, later and more powerful systems use much longer ones, forcing potential hackers to run through trillions of combinations in any attempt to find the right one by brute force. Triple DES is an enhanced version of the original DES algorithm and encrypts data three times using two different keys (providing an effective key length of 112 bits). IDEA is a 128 bit mechanism developed by the University of Zurich in 1992 and is a favourite of European financial institutions.

As you would imagine, the longer the key length, the more secure the encryption. Going back to our simple cipher, if our single digit key is represented by a letter of the alphabet, a potential hacker only has to try 26 possible combinations in order to crack the cipher using brute force. Now, if we increased the length of the key and wrote it beneath our original message (repeating the key over and over until it was equal to the length of the message), each character in the key would represent a different shift for the letter above. Of course, if short keys are used, then repeating patterns may begin to emerge in the message - the most secure method is to use a key the same length as the message itself, but this is impractical in real life situations. Combine long keys with sophisticated algorithms, however (something a little more complex than "shift each letter of the message by the value of the key character beneath") and you are in business.

Unfortunately, "secret key" or "symmetric key" cryptography (as it is known) clearly relies on both parties involved having access to the same secret key, since the sender uses the key to encrypt the message, and the receiver uses the same key (together with the same algorithm in reverse) to decrypt the message. This naturally introduces a potential problem � how do we ensure that the key is distributed in a secure manner? If we have regular contact with the person, we can pass the key face to face � you cannot get much more secure than that. In business terms, secret keys (such as bank PIN numbers) are often distributed by mail in special tamper-proof envelopes, or can be encapsulated in hardware devices such as smart cards, where the issuing authority never gives the customer access to the key information at all.

But in the case of one-off Internet transactions with hitherto unknown parties, we do not have that luxury, since as a result of the unique key-pair arrangement between the two parties, it is impossible to engage in commerce with someone to whom you have not already been "introduced".

Neither of you has a shared secret key, and there is not secure channel over which to exchange one. For this reason, secret key cryptography works best when a single issuing authority is maintaining a service for a customer base where there is some kind of registration process that takes place prior to becoming a customer.

With "public key" or "asymmetric key" cryptography, however, each person gets a pair of keys, known as the public key and the private key. The public key is generated from the private key using a complex algorithm, following which the public key can be published, whilst the private key remains secret. The mathematics behind public key cryptography are exceedingly complex, and beyond the scope of this article, so you are simply going to have to trust me on this one � any message encrypted with a given public key can only be decrypted using the corresponding private key, and there is no known way to derive the private key from the public key. Honest � this really works.

Now, if Bob wishes to send a message to Alice, he will encrypt it using Alice�s public key (which can be published in a directory or distributed via unsecured e-mail). The only person who can decrypt the resulting message is the holder of the appropriate private key � Alice. The need for sender and receiver to share secret information is eliminated, since all communications involve only public keys, and no private key is ever transmitted or shared. The best known and most widely used asymmetric key technologies are Diffie-Hellman and RSA.

Although providing the highest levels of security, public key cryptography is notoriously heavy on system resources, particularly when working on large messages. For performance reasons, therefore, RSA is usually used only to exchange keys, whilst a conventional secret-key cryptosystem (such as DES) is used for the bulk of the message.

Suppose Alice wishes to send an encrypted message to Bob. She first encrypts the message with DES, using a randomly chosen DES "secret" key which can be different for every message sent. Then she looks up Bob's public key and uses it to encrypt the DES key. The DES-encrypted message and the RSA-encrypted DES key together form a "digital envelope" and are sent to Bob. Upon receiving the digital envelope, Bob decrypts the DES key with his private key, finally using the DES key to decrypt the message itself.

The most common method for protecting electronic transactions across the Internet at the moment is Netscape�s Secure Socket Layer (SSL), which is supported by the leading browser software. SSL is a protocol for providing data security layered between application protocols (such as HTTP, Telnet, NNTP, or FTP) and TCP/IP, offering data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection.

This means that all the information in a Web browser "conversation" is fully encrypted, including the URL the client is requesting, any submitted form contents (including things like credit card numbers), any HTTP access authorisation information (user names and passwords), and all the data returned from the server to the client.

A similar, but less widely used, offering is Enterprise Integration Technologies� Secure HTTP. S-HTTP is a security-enhanced variant of HTTP which provides similar capabilities to SSL, and the two can easily co-exist in a complementary fashion by layering S-HTTP on top of SSL.

Once we have our data encrypted to prevent snoopers discovering its content, we still have to prove who we are to the other party involved in the transaction. Going back to our real-life scenario we mentioned earlier, the most important piece of evidence available to the merchant is the customer�s signature. Although it is possible to forge someone else�s signature, we have to accept that it is beyond the means of most casual thieves providing the merchant takes sufficient care when checking it.

We therefore require an electronic equivalent � something the merchant can hold up in a court of law and say "here is proof that this particular customer placed the order". Digital signatures � for that is the name of the technology involved - also provide one other useful feature: complete non-repudiation. Not only can we prove that the transaction originated from a particular source, but we can also prove that it has not been tampered with in any way during transit.

As with encryption, digital signatures can make use of either secret key (where both parties require copies of the same shared key) or public key (with a public/private key pair) methods. Once again, the public key methods � such as DSS and RSA � are more popular since key management is very much more straightforward.

Suppose Alice now wishes to send a signed message to Bob using RSA. She uses a "hash function" to create a uniquely concise version of the original text - known as a "message digest" - which serves as a very much smaller "digital fingerprint" of the message.

As with general encryption, there are several secure hash functions available such as Message Digest 5 (MD-5) or Secure Hash Algorithm (SHA). It is infeasible that different documents will have the same message digest, and even small changes in a document will cause significant changes in the digest. Next, Alice encrypts the message digest with her RSA private key (or a secret key, if preferred), and this becomes the digital signature, which she sends to Bob along with the message itself (which may or may not be encrypted).

Bob, upon receiving the message and signature, decrypts the signature with Alice's public key to recover the message digest. He then hashes the message with the same hash function Alice used and compares the result to the message digest decrypted from the signature. If they are exactly equal, the signature has been successfully verified and he can be confident that the message did indeed come from Alice. If, however, they are not equal, then the message either originated elsewhere or was altered after it was signed, and he rejects the message.

Note that for authentication, the roles of the public and private keys are converse to their roles in encryption, where the public key is used to encrypt and the private key to decrypt.

Note also that signing only guarantees integrity and authenticity, it does not guarantee privacy � encryption of the actual message content must be performed separately if required. DSS � developed for use by companies that do business with the US Government � is a signature-only system, whereas RSA can be used both for signing and generally encrypting a message.

Digital signatures provide the highest levels of data integrity, since any tampering after signing invalidates the signature. They also provide unforgeable origin authentication, since they are based on the sender�s private signing key, and authenticated by the public verifying key.

Although public key cryptography is well established and generally accepted as secure, it too suffers from one potential drawback. Since public keys are designed to be readily available, it is difficult to ensure that a particular public key does indeed belong to the person you are expecting, and is not a forgery. After all, the key is just an apparently random jumble of meaningless data, bearing no resemblance to an actual person and carrying no personal data about the owner. This means that Fred could create a false public key purporting to come from Bob, which he then publishes. Alice, wanting to send a personal message to Bob, encrypts using the forged public key. The resulting message is useless to Bob, but if Fred can intercept it, he can use his "fake Bob" private key to decrypt the content.

In the "real" business world, when we are about to do business with a complete stranger we may ask for references, or for a third party whom we know and trust to vouch for the stranger.

It would be nice to be able to do something similar in the electronic commerce world too, and as it happens we can � using something called a "digital certificate".

This is a small block of data which contains the public key together with the a confirmation of authenticity from a third party in the form of that party�s digital signature. The third party is known as a "certificate authority" (CA), and it is important that the CA is trusted in order that the certificate can be considered genuine. Probably the best know CA at the moment is VeriSign, though other systems are being introduced such as IBM�s World Registry, GTE�s CyberTrust and Nortel�s Entrust.

As things progress, it should be possible (and desirable) to have a hierarchy of CA�s, going from banks or reputable organisations at the bottom, all the way up to government bodies and even, perhaps, the United Nations. This means that if you don�t trust the first CA you can check the certificate on its digital signature with the next CA up the tree, and so on up the hierarchy until (if you are really paranoid) you reach the "root" CA.

In terms of electronic commerce, a potential customer � Alice - will first establish a certificate with a trusted CA by providing concrete proof of identity (perhaps even being required to appear in person) together with a copy of her public key. When Alice wishes to purchase her new PC from Acme Computers over the Internet, she digitally signs the order and provides a copy of the certificate.

Acme Computers checks the certificate with the CA to ensure that it has a genuine copy of Alice�s public key � it will also check to see that the certificate has not been revoked (the equivalent of a credit card company freezing your card). Certificates based on the X.509 standard (the most commonly used type) incorporate an expiry date to ensure that old certificates are revoked automatically after a given period of time, but there also needs to be a system in place to allow certificates to be revoked immediately in certain cases � say where a certificate (perhaps contained in a smart card) has been stolen.

Alice can do the same sort of checking if she wishes to verify that Acme is a genuine business, and the two parties can then begin trading, safe in the knowledge that they have genuine copies of each other�s public keys, and can thus effectively encrypt and digitally sign all future transmissions between them. This provides for complete "non-repudiation", whereby digitally signed messages can be proved authentic to a third party, such as a judge, thus allowing such transactions to be legally binding.

Digital certificates provide the foundation for SET (Secure Electronic Transactions), a group of standards developed by Visa and Mastercard for Internet commerce, and supported by, for example, Terisa Systems, Microsoft, Netscape, IBM, American Express and VeriSign.

SET provides confidentiality of payment and ordering information, since even the merchant never gets to see the customer�s payment details, which are passed directly to the card company whilst still encrypted.

This ensures integrity for all transmitted data, and provides authentication that a cardholder is a legitimate user of an account. However, the major advantage of SET over existing security systems is the addition of digital certificates that associate the cardholder and merchant both with a financial institution and the Visa or Mastercard payment system.

An important point from a security angle is that SET is designed to protect only financial information, not electronic messages or other documents, so it is not subject to U.S. government export restrictions. This means that SET-based systems will be able to incorporate full 128-bit encryption outside the USA and Canada.

The ability to "extend" a certificate is also inherent within the X.509 standard, providing the means to hold additional personal information - such as a credit limit, perhaps - within the certificate itself. In the future � as we move towards an increasingly cashless society � public key certificate details can be stored securely in devices such as smart cards, providing a truly portable and secure (providing you keep your smart card safe) means of performing electronic transactions. Although SET will initially be implemented in software, both Visa and Mastercard have stated that they will work with standard groups and vendors to ensure that the migration of credit cards to the use of chip technology is compatible with SET.

One of the most significant findings of The State of Web Commerce report from O�Reilly mentioned earlier, is the census of fully-enabled servers capable of secure communications. Of 648,613 publicly visible Web servers surveyed, 525, 915 responded to standard HTTP requests on port 80, identifying themselves as normal Web servers. When those same servers were queried on port 443, only 65,407 (around one in ten) responded with HTTPS (ordinary HTTP, but exchanged over an SSL-encrypted session).

However, among these, only 3,239 offered a valid certificate signed by a trusted third party. If we therefore approach the question of commerce-readiness with consumer confidence in mind, then only 3,239 � or roughly one half of one per cent of sites surveyed � meet the two criteria (encryption and third-party signed certificates) established for fully-enabled secure communications.

Another key (no pun intended!) point to bear in mind is that 60 per cent of those sites are currently using strong encryption (128 bit as opposed to exportable 40 bit), and almost 94 per cent of those are located in North America. This is hardly surprising given the American regulations prohibiting the export of products incorporating strong cryptography. Despite the EU initiative to establish an international cryptographic infrastructure, together with the recent appearance of "home grown" strong cryptography products, the fact remains that the majority of the software we use today comes from the US.

Although there are plenty of airtight encryption systems developed in Europe, they do tend to be more expensive than their US counterparts and it is often impractical to add them to a network that already has a large installed base of US equipment.

Before January 1997, US companies were only allowed to ship encryption products based on 56 bit DES out of the US if they were going to foreign subsidiaries (more than 50 per cent US-owned) or to banks. The American-imposed export restrictions were therefore often seen as a major barrier to the widespread adoption of electronic commerce outside the US, given that 40 bit encryption is seen as too weak for commercial use in connection with financial transactions. Now, however, there are signs of improvement in this situation.

An executive order � regarding Administration of Export Control on Encryption Products � took effect in the US on January 1, 1997, effectively allowing all vendors to begin shipping 56 bit key encryption products world-wide providing they agree to add Key Recovery to their products within two years. Once fully compliant with the US Government-imposed Key Management Infrastructure (KMI), vendors are then at liberty to begin exporting stronger encryption, using unlimited key lengths.

Initial proposals for Key Recovery are based around "Key Escrow", also known as "Trusted Third Party". There are a number of implementations of this, each of which involves providing a Key Recovery Centre (KRC) with the means to decrypt your encrypted sessions. One way this could work, for instance, is to provide the KRC with copies of your private keys. Another method is to embed the keys used to encrypt the message within the message itself in a "Key Recovery Field". This is then encrypted using yet another public key provided by the KRC, whilst the corresponding private key remains known only to the KRC

In all implementations, however, the theory is that KRC�s can only be forced to recover keys on presentation of a court order, thus protecting the interests of end users. In the UK, KRC�s would be licensed by the Department of Trade and Industry (DTI), and the job of issuing warrants requiring disclosure of keys to law enforcement agencies would rest with the Home Secretary. At the moment, products incorporating Key Recovery can make use of one of three proprietary, dynamic key management protocols � Internet Security Association/Key Management Protocol (ISA/KMP) Oakley (backed mainly by Cisco); Simple Key Exchange Internet Protocol (SKIP), backed by Sun; and Photuris Session Key Management Protocol, backed by Radguard.

Trusted Third Party Key Recovery has been heavily criticised by most of its likely users due to the potential for the criminal element to target Key Recovery Centres in an attempt to gain access to thousands of sets of data in a single swoop. To the hacker, KRC�s represent an extremely valuable single point of failure for the system as a whole, made worse by the proposal that some KRC�s would use a single key for many users.

There is also the feeling, of course, that it does not make commercial sense to allow any third party � even a "trusted" one � to hold keys which could provide access to our most sensitive corporate data.

There has been a great deal of hype surrounding the Internet over the last year or two, and for every positive story there have been a couple of negative ones � usually security related.

As we move forward into the world of Internet commerce, it is important to keep things in perspective. Whatever the risks inherent in new technologies and opportunities, business practices must continue to evolve. In order to move forward, we must accept some of those risks, whilst doing our utmost to minimise them as far as is humanly - and technologically - possible.

No one product or technology will solve all your security problems, but with numerous vendors rallying behind the key standards, it will hopefully not be too long before we see interoperability between different firewall, encryption and authentication products. In the meantime, as the US stranglehold on the encryption market eases, we don�t have to look too far for a comprehensive solution to our electronic commerce requirements.

At the end of the day, the Internet is open and ready for business � are you?