 |
|
|
Security In Internet Commerce Every time you engage in a commercial transaction of any sort on the Web, send sensitive information via e-mail, or even simply browse a Web site, you are in danger of revealing private information about yourself or your company to individuals or groups that will modify that information, sell it to third parties or otherwise use that data for malicious purposes. The necessity of reliable, fast data interchange is the reason for the Internet’s existence. But if you cannot preserve the confidentiality and integrity of your data, then the ‘Net potentially can cause you more harm than good. In order to protect our personal information to the extent which it deserves, we need just one tool – encryption. Encryption 101 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 three 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. Digital Signatures 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. In a face-to-face commerce transaction, 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 DES 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 unforgettable origin authentication, since they are based on the sender’s private signing key, and authenticated by the public verifying key. Certificates 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. Summary 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. |
Security Testing |
Send mail to webmaster
with questions or
|