Passwords and passcodes are the most common way of authenticating users. Examples of their use includes the PIN (Personal Identifier Number) you use with your debit and credit card as well as the many passwords you are expected to remember when logging in to computer-based services.
Transparent Data Encryption (TDE) enables you to encrypt an entire database.
TDE protects the database against unauthorized third parties gaining access to the hard disks or backups on which the database is stored. TDE encrypts the database by using a Database Encryption Key (DEK) that is stored in the database boot record.
The DEK is in turn protected by the database master key, which is in turn protected by the service master key. You can use BitLocker Drive Encryption, a full-volume encryption method supported by Windows Server 2008 and Windows Server 2008 R2, although this will not ensure that database backups are encrypted.
NOTE TDE AND TEMPDB
If any database on the instance uses TDE, the tempdb system database will also be encrypted.
To use TDE to encrypt a database, you must perform the following steps:
1. Create the master encryption key.
2. Create the certificate protected by the master key.
3. Create a DEK and protect it by using the certificate.
4. Encrypt the database.
The first step in deploying TDE involves creating a master encryption key. You do this by using the CREATE MASTER KEY ENCRYPTION BY PASSWORD statement. For example, you can accomplish that by using the following query:
MASTER KEY ENCRYPTION BY PASSWORD = ”;
After you have created the master encryption key, the next step involves creating the certificate that will be used to encrypt the database. You can accomplish this by using the CREATE CERTIFICATE statement. For example, to create a certificate named ServerCertificate that uses the subject name Server Certificate, use the following query:
CREATE CERTIFICATE ServerCertificate WITH SUBJECT = ‘Server Certificate’;
When the master key and certificate are in place, you can create the DEK for the specific database. You do this by using the CREATE DATABASE ENCRYPTION KEY statement. For example, the following query creates a DEK for the AdventureWorks2012 database:
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE ServerCertificate;
After all the appropriate keys and certificates are in place, you can encrypt the database by using the ALTER DATABASE statement. For example, to encrypt the AdventureWorks2012 database, use the following query:
ALTER DATABASE AdventureWorks2012
SET ENCRYPTION ON;
When using TDE, you should create a backup of the server certificate in the master database. If you lose the database server without backing this up, you cannot access data in a database protected by TDE. You can use the BACKUP CERTIFICATE statement to cre- ate a backup of the certificate and private key, both of which are required for certificate recovery. The private key password does not have to be the same as the database master key password. For example, the following code, when run from the master system database, creates a backup of the ServerCertificate certificate to a file called ServerCertExport and a PrivateKeyFile private key:
BACKUP CERTIFICATE ServerCertificate
TO FILE = ‘ServerCertExport’
WITH PRIVATE KEY (
FILE = ‘PrivateKeyFile’,
ENCRYPTION BY PASSWORD = ” );
SQL Server will write these backup files to the MSSQLDATA directory of the instance.
Encryption, in one form or another, has been around since almost the dawn of civilization. Computers and networks have made advanced forms of encryption possible. The kinds of encryption historically used (for example, secret decoder rings or German Enigma machines) are trivial to break on a computer, taking only seconds. Almost all versions of UNIX come with a program called crypt, which is a software implementation of the German Enigma machine used in World War II. A program exists on the Internet that breaks this code in seconds. Therefore, when dealing with encryption, always insist on using high-quality algorithms; weak ones can be broken easily.
Digital signatures are a way of securely signing documents. This strategy is useful for two reasons. The first is like a regular signature-to indicate that you agree with the terms of the document. The second is to detect whether someone has changed the document after you signed it (something that was unlikely with traditional paper documents). Digital signatures are implemented by making a digest of the message, using an algorithm such as MD5. This digest is encrypted by the user’s key. The recipient can decrypt the encrypted digest and compare it to the document. If the document doesn’t match, it has been tampered with or has a forged signature.
When writing Internet programs that involve encryption, it’s very important to be aware of the legal issues involved. If you don’t, you could end up in prison on felony charges.
First, some countries ban outright any use of encryption. France and Iran are two notable examples. Therefore, you shouldn’t write any encryption code, import any encryption programs, or even use encryption in these two countries. Other countries might have such laws on the books. I recommend checking with an attorney unless you are absolutely sure of the legal status in your country.
The United States is another country with strange laws about encryption. No problem exists with using any form of encryption you want-within the country. The trouble starts when you want to write a piece of encryption software in the United States and then export it to another country (except possibly Canada) in electronic form. The U.S. government has labeled certain types of encryption software as munitions-just as if these programs were missiles or something. The law is known as ITAR (International Traffic in Arms Regulations).
It’s possible to write certain types of weaker encryption programs for export. You then have to request an exemption from the export law from the U.S. government. The level of encryption allowed is strong enough to be time-consuming for a cracker to break the code, but it can be done in a few months on some machines. For public key algorithms, covered in the section “Public Key Encryption,” the Software Publishers Association (SPA) and the government agreed to give quicker approval to algorithms using 40-bit keys or less. A message encrypted with a 40-bit key takes only about 200 MIPS/year of CPU time (that is, a 200 MIPS computer would take one year to crack it). Therefore, any highly secure, non-time-sensitive communication is potentially at risk. Keep this fact in mind.
A few ways exist to get around this law. The best is to just write your software outside the U.S. Some people ask the question, “What if my machine is out of the country, but I’m in the U.S.?” or vice versa. My answer is that there’s no legal precedent on this issue, so don’t take chances. The other alternative is that apparently you can print out the source code (or binary) to the program and carry the printouts out of the country without violating the law. Then, in the foreign country, you can scan them back in. Again, check with your lawyer before attempting this. Another method is for you to write a U.S. version of the program that you tightly control, and then have an associate write an international version outside the U.S. This has been done with PGP (Pretty Good Privacy), which is discussed later in this chapter.
To make matters even worse, the law even precludes giving the program to people in the U.S. who are not U.S. or Canadian citizens or permanent residents. I know this part of the law is widely violated, but my recommendation, as always, is to play it safe.
Another legal issue is that the major public key encryption algorithms are all patented. The patent owners are pretty aggressive about protecting their patents; however, many of the key patents expire in the next couple of years. The release of these patents will break the stranglehold the patent holders have had on public key encryption. I predict that after the patents expire we’ll see many more public key encryption implementations than we have today.
Private key encryption is the oldest form of encryption in existence. In private key encryption, there is one key. You encrypt the message, using this key. The person decrypting the message must have the same key. It works just like the secret decoder rings you might have played with when you were a child.
The strength of private key encryption algorithms varies greatly. Some are trivial to crack; others are computationally impossible to crack, given today’s computers. Some vendors, notably WordPerfect, have included some private key encryption code in their products. It turns out that many of these are almost completely useless. You can download programs from the Internet to crack the keys, run them, and have the original file back in under 15 minutes (the download is the time-consuming part, too!).
The most famous private key encryption algorithm is DES (Data Encryption Standard). It’s very popular, and you can find implementations for almost any platform available today. However, DES is aging (originally published in 1975) and computers are getting faster. Attacks on DES are becoming increasingly possible. A modified version of DES known as Triple-DES is available and is harder to crack.
The big problem with private key encryption is making sure that the people on both ends of the communication have the keys-without anyone else having them. The only ways to exchange keys in a secure fashion are to already have a secure communication channel available, which means that both parties already have encryption available; or both people must be in the same place without anyone else around, so that they can be sure they’re not being bugged. This is very cumbersome for most people.
Public key encryption eliminates the need for a secure key-exchange mechanism. Each person has a private key, which he uses to decrypt or digitally sign messages, and a public key, which others use to send messages to him or to verify his digital signature. Each person keeps his private key private to himself. The public key is public information and can be known by anyone.
The length of the key is a critical issue in the security of a public key encryption algorithm. The longer the key, the safer your encrypted messages but the longer it takes to encrypt or decrypt them. My advice is to go ahead and use a long key (1024 bits or more). Most people today have enough CPU horsepower to encrypt messages to you quickly, even with a long key. This isn’t true when breaking messages without knowing the key, however. The longest message known to be broken had a 429-bit key. It required an international effort, involving 600 sites. The good news is that the amount of time needed with current cracking algorithms doubles with every additional 10 bits of key length. However, computer performance and algorithms to break public key encryption algorithms are improving, making cracking easier. Therefore, a long key is essential in protecting your messages for a long period of time.
With public key encryption, the main implementation difficulty changes from key exchange to identity verification. If someone e-mails you her public key across the Internet, how do you know it’s really from her? The answer is that you don’t. The secure way is to get together with the person, in person, and exchange public keys. Well, if you do this, you almost might as well have used private key encryption and exchanged keys. Also, this model doesn’t scale well. Obviously, you can’t meet with every single person with whom you need to exchange public keys.
Two basic models for key exchange have been developed. The first is a hierarchical approach. At the top is a person or organization that everyone has to trust. This person/organization hands out authority to other organizations or people who can authenticate certain groups of people. These second-tier authenticators then publicly publish the public keys of the people they authenticate. This is the simplest form of this scheme. It’s possible (and probably necessary) to have many more levels than this.
Organizations or individuals can issue a special document known as a “Digital Certificate” saying that they have authenticated a certain person. Then that person can show the digital certificate to others as proof of her identity on the Internet. These digital certificates are usually in a format known as X.509. One company issuing digital certificates is VeriSign (http://www.verisign.com/). To use the Netscape FastTrack Server, you have to acquire a digital certificate from VeriSign, though it should be possible to use other companies in the near future (probably by the time you are reading this).
The other model, known as the Web of Trust, doesn’t depend on being able to trust these higher-level people and organizations. In the Web of Trust, you initially exchange keys with at least a few people you meet in person. Both of you can digitally sign each other’s keys with your names. Then, when others later get your key over the network, they see that it’s signed by the person with whom you exchanged keys in person. If they have exchanged keys in person with that person and trust that person, they then know that they can trust your key.
To make this system work well, you have to decide how much you trust other people’s ability to validate and exchange keys correctly. If you exchange keys with someone you don’t think validates people correctly, you can later ignore any key you get over the network that is signed by that person and not signed by someone you do trust. If you trust their validation techniques, you take any keys signed by them. You can also partially trust them with some implementations of this model. When you start thinking about scaling this model, your head will probably start to spin, but it’s a powerful way for small groups of people to communicate without a lot of overhead.
Most people tend to be rather religious about which model of key exchange is the best. However, in reality, it has been proven mathematically that either model can emulate the other model with a little work. In fact, converting the Web of Trust into the hierarchical approach is almost trivial. An organization only needs to create a key and then sign the keys of people whom they can authenticate. If people know they can trust that organization, they will accept keys that are signed by the organization as being valid.
My personal belief is that both methods are flawed in some ways. Therefore, this ability to twist one model into acting like the other is essential. Sometimes you want to get keys from a central authenticated database, especially when you can’t meet this person in person or can’t meet someone who can meet them to handle the key exchange. At other times, you want to get a key directly from someone (or slightly indirectly, from a source you personally trust), so that you know it’s absolutely correct.
Popular Public Key Packages
The most popular piece of public key encryption software on the Internet is PGP (Pretty Good Privacy). PGP is available for numerous platforms and uses the Web of Trust model of key exchange. To get around the legal restrictions, there’s a U.S. version of the program and a separate international version that was written outside the U.S. Therefore, you can use PGP without worrying about the export controls. (Just don’t carry a copy on your laptop from inside the U.S. to other countries!) In reality, at least two U.S. versions of PGP exist. A version for noncommercial use is freely available by signing some documents with MIT. There’s also a commercial version known as ViaCrypt PGP.
PEM (Privacy-Enhanced Mail) is another algorithm for public key encryption. PEM is based on the hierarchical key exchange model. RIPEM (Riodran’s Internet Privacy-Enhanced Mail) is the reference implementation, which is available from RSA Data Systems. PEM seemed destined for greatness a couple of years ago, but it really has taken a back seat to PGP in actual use.
MOSS (MIME Object Security Services) is intended to correct a couple of the flaws of PEM, one being that PEM’s rigid hierarchies are too strict on many occasions. MOSS relaxes the restrictions somewhat. MOSS is designed to handle MIME messages, unlike PEM. MOSS has too many options, and it might be possible for two different vendors to write MOSS implementations that can’t speak to each other. Some people at the Internet Engineering Task Force (IETF) told me and others to forget PEM, and that MOSS is the algorithm for the future. However, upon researching for this chapter, I found material on the Web indicating that MOSS is a niche system and that PEM was still alive and well. I recommend watching market trends on this debate to see which side is better to use and is gaining market share.
SSL (Secure Socket Layer) is a security protocol developed by Netscape. In the protocol stack, it runs above the TCP protocol but below the application layer protocols such as NNTP, HTTP, and FTP. While I am writing this, SSL has been implemented only in uses related to HTTP.
SSL enables the client to authenticate the server. It also enables data being transmitted over the Internet to be encrypted. If you are using Netscape Navigator, you can know you are talking to an authenticated server when the key in the lower-left corner of the window is in one piece and not broken. If you have the exportable version of Netscape Navigator, it uses only the 40-bit key discussed earlier (in the section dealing with U.S. export restrictions). So, this isn’t a very secure system.
The current version that is implemented is SSL 2.0. However, the SSL 3.0 specification is available; 3.0 enables the client, as well as the server, to be authenticated.
An SSL server runs on two ports. First, it runs normal, unencrypted as always. Also, it answers on a second port, 443 by default, for encrypted transactions. If your URL for unencrypted transactions ishttp://www.utdallas.edu/, for example, your URL for encrypted transactions is https://www.utdallas.edu/. The only difference is at the beginning of the address: https instead of http.
At the current time, SSL is implemented in the Netscape FastTrack Server, recent versions of the NCSA server, and Open Market’s Secure Web Server. Patches are also available for the popular, free Apache Web server. SSL also is implemented in Netscape Navigator on the client side. For more information, see the following address:
If you need to combine SSL with a proxy-based firewall, see this address for a specification of how to do it:
S-HTTP (Secure HyperText Transfer Protocol) is a higher-level encryption scheme than SSL to protect Web transmission. Although S-HTTP and SSL seem to be in competition, it has been discussed that there’s no reason not to use both in conjunction with each other. In fact, Open Market has implemented both in its Secure Web Server product. Netscape is considering support of S-HTTP as well as SSL in its products. URLs using S-HTTP start with s-http://.
The S-HTTP specification is being developed by CommerceNet and can be seen at the following addresses:
You can find more information at http://www.eit.com/creations/s-http/. An S-HTTP server can be found at http://www.commerce.net/software/Shttpd. Patches for the CERN httpd server can also be found at these locations. There’s also a version of Mosaic called Secure Mosaic, but it’s available only to CommerceNet members.
Shen is a proposal similar in nature to S-HTTP. It hasn’t received widespread support. However, it’s being developed by Phillip Hallam-Baker of the W3 Consortium; and because it is one of the key players in the Web standards world, you should keep an eye on it just in case. The message format it uses is inspired by PEM but unfortunately is not compatible with it. Shen is discussed at these addresses:
S/MIME (Secure/Multipart Internet Mail Extensions) is a standard to exchange e-mail in encrypted form. The specification can be found at http://www.rsa.com/rsa/S-MIME.
Like PGP, the public key encryption is just to manage key exchange; the bulk of the encryption is done with private key encryption algorithms. S/MIME is flexible and enables the use of DES, Triple-DES, and RC2 as private key encryption algorithms.
GSS-API (Generic Security Service-Applications Programming Interface) is a program interface for security that includes both client and server authentication as well as data encryption. It’s “generic” because it was designed to work with any Internet service that needs security. When used with HTTP, the URLs start with gss-http://. GSS-API has its supporters, but hasn’t been deployed much. It’s an interesting approach, though. More information can be found at this address:
SET (Secure Encryption Technology) is a standard for exchanging credit card transactions across the Internet. It was developed by a group including MasterCard, Visa, Netscape, IBM, Microsoft, VeriSign, and GTE. American Express has shown support for it more recently. The major credit card companies state that they don’t see encryption technology as a point of difference between them. They all agree that all transactions should be secure-whether by them or their competition.
Because SET has the backing of so many major players in the electronic commerce world, it definitely bears watching. Expect that you will see the beginning of deployment in late 1996. It also is using X.509 certificates, just like SSL.
The SET standard is documented at this location:
More technical information is available at
It’s important to take the precautions to protect you and your products from information theft these days, because it’s getting easier and easier for people to share digital products. Information theft is a type of computer security risk and it’s defined as stealing an individual’s personal or confidential information. When this is stolen this can cause as much damage, or possibly more then hardware or software theft.
Business or home users are both at risk of information theft. One example is a malicious individual stealing credit cards so they can make unauthorized purchases on another person’s account. If information is transmitted over a network then it has a very high chance for malicious users to intercept the information. Every computer in the path of your data can see what you send, and they can also see what you send. A lot of companies try to stop information from being stolen by applying some user identification and authentication controls. These constraints are best for protecting computers along a company’s premise. However, to protect information on the Internet and on networks, companies use a handful of encryption methods.
Encryption refers to the process of converting data into an unreadable form. One type of encryption software is Obfuscated code which is a programming language that is extremely hard to read. Encrypted data is like any other data because you can send it through a lot of options, but to read it you must decrypt or decipher it into a more readable form. Throughout the encryption process, the unencrypted data or input is known as plaintext and the encrypted data, or output is known as ciphertext. To encrypt information, the programmer converts the plaintext into ciphertext using some type of encryption key. An encryption key is the programmed formula that the person who receives the data uses to decrypt the ciphertext.
There are a variety of encryption or algorithm methods. However, with an encryption key formula, you will be using more then one of these techniques. Some business use available software, while others develop their own. When an individual send information online such as through an email for example, they will never know who might intercept it, or to whom it could possibly be forwarded to. That’s why it’s not such a good idea to send confidential information online. However, an individual can help protect themselves by encrypting the information, or signing it digitally. Some very popular email encryption software is known as Pretty Good Piracy (PGP) and Centurion Soft Secure Protection.
Pretty Good Piracy is known as freeware, which means that individuals can use it for their personal needs but not for commercial purposes. You can download this for no cost. A digital signature is a type of encrypted code that a individual, website, or company pastes to an electronic document to make sure that the individual is who they claim to be. The code will most likely consist of the user name and a hash of usually part of the message. A hash is a type of mathematical formula that generates content from a specific message, so it is different from a message. The recipient will have to generate a new hash from the received message and compares it from the one with the digital signature to make sure that they match appropriately. The main purpose behind using digital signatures is to make sure that it’s not a deceiver participating in the transaction. So, digital signatures help narrow down e-mail scams. A digital signature can also make sure that contents of a message have not been changed. A lot of web browsers use encryption that is regarded as 40 bit encryption, and this is a very low level. A variety of browsers also offer 128 bit encryption which has a higher level of protection because the encryption key is longer. Some important places that require extremely hire security like banks, and online retailers needs at least 128-bit encryption. A website that successfully uses encryption methods to secure information is known as a secure site. A secure site uses digital certificate with security protocol. The two most popular security protocols are secure sockets layer, and secure HTTP.
A digital certificate is a notice that verifies that a user or a website is for real or not a scam. A lot of ecommerce websites will usually have digital certificates. A certificate authority (CA) is an authorized company or individual for that matter that has the ability to issue and verify digital certificates. There are several of websites that offer a digital certificate. Some popular ones are Verisign http://www.verisign.com/, Godaddy www.godaddy.com, Digicert http://www.digicert.com/, and Thawte http://www.thawte.com/.
The digital certificate will usually contain information such as the username and the serial number of the certificate. By the way, the information in the digital certificate is also encrypted. Next, the Secure Sockets Layer (SSL) provides encryption of every detail that passes between a server and a client. SSL also requires the client to have a digital certificate, so the web browser can communicate securely with the client. The web pages that use SSL will usually begin with https as opposed to http. SSL is available in 40 and 128-bit encryption. Secured HTTP (S-HTTP) allows individuals to choose encryption for data that pass through a client and a server. When using S-HTTP, the client and the server must have a digital certificate. This makes S-HTTP more difficult to use then SSL, but on the other hand, it is more secured. Companies that have to use verify a client such as online banking companies use S-HTTP.
Also, mobile users can also access computer networks through a virtual private network. When mobile users successfully logon to a main office using some type of standard Internet connection, a virtual private network (VPN) allows the mobile user to secure the connection. VPNs encrypt data as it passes from a notebook computer or any other mobile device so it won’t be intercepted. Regardless of your security method, I will highly recommend using the most powerful safeguard which is a backup. It prevents data loss from several of sources such as system failure for one. A backup is simply a backup of a file, program, or desk that can be used in place of the original if its loss, destroyed, or corrupted. If the files are destroyed, then you can replace them by restoring it, which copies the backed up files into their original position in the computer.
This is a white paper dedicated to Digital Certificates & Encryption, how they work and apply to Internet Commerce
The Need for Security
On the Internet, information you send from one computer to another passes through numerous systems before it reaches its destination. Normally, the users of these intermediary systems don’t monitor the Internet traffic routed through them, but someone who’s determined can intercept and eavesdrop on your private conversations or credit card exchanges. Worse still, they might replace your information with their own and send it back on its way.
Due to the architecture of the Internet and intranets, there will always be ways for unscrupulous people to intercept and replace data in transit. Without security precautions, users can be compromised when sending information over the Internet or an intranet. This has serious implications for Internet Commerce. For Internet Commerce to exist, there has to be a means to secure data sent over the Internet. Without a secure means of communication, commerce cannot exist.
How do I protect my data?
Encryption & Digital Certificates are the solution for Internet Commerce. Used together, they protect your data as it travels over the Internet.
Encryption is the process of using a mathematical algorithm to transform information into a format that can’t be read (this format is called cipher text). Decryption is the process of using another algorithm to transform encrypted information back into a readable format (this format is called plain text).
Digital Certificates are your digital passport, an Internet ID. They are verification of you who you are and the integrity of your data.
Combined, encryption and digital certificates protect and secure your data in the following four ways:.
* Authentication: This is digital verification of who you are, much in the same way your driver’s license proves your identity. It is very easy to send spoofed email. I can email anyone in the world pretending I am the President of the United States. Using standard email, there is no way to verify who the sender is, i.e. if it is actually the President. With digital signatures and certificates, you digitally encode verifiable proof of your identity into the email.
* Integrity: This is the verification that the data you sent has not been altered. When email or other data travels across the Internet, it routes through various gateways (way stations). It is possible for people to capture, alter, then resend the message. Example, your boss emails the company president stating that you should be fired. It is possible for you to intercept that email and change it saying you deserve a $10,000 raise. With digital certificates, your email cannot be altered without the recipient knowing.
* Encryption: This ensures that your data was unable to be read or utilized by any party while in transit. Your message is encrypted into incomprehensible gibberish before it leaves your computer. It maintains it encrypted (gibberish) state during it’s travel through the Internet. It is not de-crypt until the recipient receives it. Because of the public-key cryptography used (discussed later) only the recipient can decipher the received message, no one else can.
* Token verification: Digital tokens replace your password which can be easily guessed. Tokens offer a more secure way of access to sensitive data. The most common way to secure data or a web site is with passwords. Before anyone access the data, they are prompted with their user login id and password. However, this is easily cracked using various security software (such as Crack 5.0, etc.). Also, passwords can be found with other means, such as social engineering. Passwords are not secure. Token verification is more secure. Your digital certificate is an encrypted file that sits on your hardrive. When you need access to a system, that systems asks you for your digital certificate instead of a password. Your computer would then send the certificate, in encrypted format, through the Internet, authorizing you for access. For this to be compromised, someone would have to copy this file from your computer, AND know your password to de-crypt the file.
How does it all work?
To understand how this all works, we need to start with the basics. Encryption has been around for centuries, Julius Caesar used encrypted notes to communicate with Rome thousands of years ago. This traditional cryptography is based on the sender and receiver of a message knowing and using the same secret key: the sender uses the secret key to encrypt the message, and the receiver uses the same secret key to decrypt the message. For Caesar, the letter A was represented by the letter D, B by the letter E, C by the letter F, etc. The recipient would know about this sequence, or key, and decrypt his message. This method is known as secret-key or symmetric cryptography. Its main problem is getting the sender and receiver to agree on the key without anyone else finding out. Both sides must find some “secure” way to agree or exchange this common key. Because all keys must remain secret, secret-key cryptography often has difficulty providing secure key management, especially in open systems with a large numbers of users, such as the Internet.
21 years ago, a revolution happened in cryptography that changed all this, public-key cryptography. In 1976, Whitfield Diffie and Martin Hellman, introduced this new method of encryption and key management. A public-key cryptosystem is a cryptographic system that uses a pair of unique keys (a public key and a private key). Each individual is assigned a pair of these keys to encrypt and decrypt information. A message encrypted by one of these keys can only be decrypted by the other key in the pair:
* The public key is available to others for use when encrypting information that will be sent to an individual. For example, people can use a person’s public key to encrypt information they want to send to that person. Similarly, people can use the user’s public key to decrypt information sent by that person.
* The private key is accessible only to the individual. The individual can use the private key to decrypt any messages encrypted with the public key. Similarly, the individual can use the private key to encrypt messages, so that the messages can only be decrypted with the corresponding public key.
What does this mean?
Exchanging keys is no longer a security concern. I have my public key and private key. I send my public key to anyone on the Internet. With that public key, they encrypt their email. Since the email was encrypted with my public key, ONLY I can decrypt that email with my private key, no one else can. If I want to encrypt my email to anyone else on the Internet, I need their public key. Each individual involved needs their own public/private key combination.
Now, the big question is, when you initially receive someone’s public key for the first time, how do you know it is them? If spoofing someone’s identity is so easy, how do you knowingly exchange public keys, how do you TRUST the user is really who he says he is? You use your digital certificate. A digital certificate is a digital document that vouches for the identity and key ownership of an individual, a computer system (or a specific server running on that system), or an organization. For example, a user’s certificate verifies that the user owns a particular public key. Certificates are issued by certificate authorities, or CAs. These authorities are responsible for verifying the identity and key ownership of the individual before issuing the certificate, such as Verisign.
Authentication & Integrity
We now have a secure means of encrypting data, one of the four methods of securing data on the Internet. Two others, authentication and data integrity, are combined in what is called a digital signature. A digital signature works as follows:
* Authentication: a specific individual sent a message (in other words, no impersonator claiming to be the individual sent the message).
* Integrity: this particular message was sent by the individual (in other words, no one altered the message before it was received).
When you email someone, your public/private key combination creates the digital signature. It does this using the following format:
1. The sender uses a message-digest algorithm to generate a shorter version of the message that can be encrypted. This shorter version is called a message digest. Message digests and message-digest algorithms are explained in the next section.
2. The sender uses their private key to encrypt the message digest.
3. The sender transmits the message and the encrypted message digest to the recipient.
4. Upon receiving the message, the recipient decrypts the message digest.
5. The recipient uses the hash function on the message to generate the message digest.
6. The recipient compares the decrypted message digest against the newly generated message digest.
* If the message digests are identical, the recipient knows that the message was indeed sent by the person claiming to be the sender and that the message was not modified during transmission.
* If the message digests differ, the recipient knows that either the message was sent by someone else claiming to be the sender or that the message was modified or damaged during transmission.
The encrypted message digest serves as a digital signature for the message. The signature verifies the identity of the sender and the contents of the message.
If the message is sent by someone claiming to be the sender, this person does not have access to the sender’s private key. The person claiming to be the sender must use a different private key to encrypt the message digest.
Because the recipient uses the sender’s public key to decrypt the message digest (and not the actual public key corresponding to the private key used to encrypt the message digest), the decrypted message digest will not match the newly generated message digest.
If the message was modified during transmission, the hash function will generate a different message digest when applied after the transmission.
Tokens represent the fourth security option by replacing passwords. Tokens are simply your digital certificate residing on your hardrive. When a computer prompts you for your password, your computer sends your certificate over the Internet instead. Your certificate verifies your identity instead of the password. This is a more secure (and easier) means of verification.
How Secure is all This?
Just how secure is encryption. The strength of encryption is measured in bits, or how big the key is. The bigger the key, the stronger the encryption. There are currently 3 commonly used key sizes used commercially, 40, 56, and 128 bit. Originally, the government allowed only 40 bit keys for exportation. However, this proved far to weak for security. In February of 1997, a college student was able to crack 40 bit encrypted data within 4 hours .
Berkeley — It took UC Berkeley graduate student Ian Goldberg only three and a half hours to crack the most secure level of encryption that the federal government allows U.S. companies to export.
Yesterday (1/28) RSA Data Security Inc. challenged the world to decipher a message encrypted with its RC5 symmetric stream cipher, using a 40-bit key, the longest keysize allowed for export. RSA offered a $1,000 reward, designed to stimulate research and practical experience with the security of today’s codes.
Goldberg succeeded a mere 3 1/2 hours after the contest began, which provides very strong evidence that 40-bit ciphers are totally unsuitable for practical security.
In June of 1997, a organized group of people were able to crack 56 bit DES encryption in 140 days. This group shared their resources throughout the Internet utilizing software called DESCHALL. With a possible 72 quadrillion keys to test, this distributed attack would require an incredibly large amount of computing power. And compute the DESCHALL team did, at some points testing almost seven billion keys per second.
In the end, the DESCHALL effort solved the DES challenge after only searching 24.6% of the key space. (about 18 quadrillion keys!) The winning key was determined by Michael Sanders, using a Pentium 90 MHz desktop PC with 16 megs of RAM.
Many believe this security is good enough. By the time your data can be compromised, (3 months) it is of little value because it took so long. However, to truly ensure the security of your data, most Internet Commerce uses 128 bit encryption. Keep in mind, key strength increases exponentially, making 128 bit encryption thousands of times more difficult to compromise. Because of its strength, the government has prohibited its exportation, it can only be used within the United States. At this time, no one has cracked this encryption. 128 bit encryption is expected to remain secure well past the year 2000.
What it Looks Like
Below is an example of a message that has been encrypted and signed, but intercepted before the recipient has received it. Notice how the body of the entire message is “gibberish”, i.e., the message cannot be read. That is what encryption looks like.
Below is an example of the same message, but received by the intended recipient. The recipient has decrypted the message and verified the message’s integrity & /authenticity. The protocol or Internet standard used for Digital Certificates is X.509 & S/MIME. Any email system that has these open based standards can use Digital Certifcates for Internet Commerce. The image below is of Netscape Navigator, which is both X.509 and S/MIME compliant.
Utilizing digital certificates and encryption, users can easily and securely communicate on the Internet. This combination of ease of use and security lays the foundation for commerce. As users gain confidence and experience using these tools, Internet Commerce, much like encryption, will grow exponentially.
Previously I have demonstrated to you what a person with very little knowledge can find out about you just by knowing your Email address. Now it is obvious that to keep your privacy, you need to sign up for a free Email account (such as Hotmail [hotmail.com], Yahoo mail [mail.yahoo.com], ZDNet Mail [zdnetmail.com], Net @ddress [netaddress.com], Bigfoot [bigfoot.com] etc’). But what if you had a special Email address on a free server that automatically forwards all incoming Email to your real mailbox and keeps all the information discreet?
These are called Anonymous Remailers. Most of them are free and live out of contributions and/or sponsor banners they place on their website.
You can find many many Anonymous Remailers at http://www.theargon.com.
Here’s a good example for an Anonymous Remailer:
First, head to http://anon.isp.ee (by the way, the extension .ee stands for Estonia) and sign up your free account. Once you’re a registered user, send an Email to email@example.com with no subject and the following content:
user: your username
pass: your password
realaddr: your recipient’s Email address.
realsubj: the subject of your mail.
Example: if I want to send an anonymous mail containing the following:
Subject: ANONYMITY RULEZ!!
This is an anonymous Email message.
Let’s see you trace me now!
to firstname.lastname@example.org, and your username is user and your pass is pass, send the following Email to email@example.com (remember not to enter a subject):
realsubj: ANONYMITY RULEZ!!
This is an anonymous Email message.
Let’s see you trace me now!
You’ll receive an Email notification from anon.isp.ee once your message has been delivered. Once your recipient will reply to this Email, the message will return to you.
You can also use web-based anonymous remailers such as Replay Associates , but it won’t let you receive replies.
Everyone can read your Email. Whether it’s some script kiddie who hacked your Hotmail account, a skilled cracker (or a script kiddie with a lot of free time) that hacked your POP3 mailbox or a person who got your Email by mistake. If you don’t want other people to read your Email, use PGP.
Everyone who uses PGP can have their own PGP key. A key consists of tons of characters, whether they are lowercase or uppercase letters, number or symbols. After you make your key, you need to transfer it to everyone you want to send encrypted mail to. Once they have it, you can start sending encrypted mail to them and they’ll be able to use your key to decrypt it.
Note: PGP is very strong and can only be broken with giant supercomputers. The longer your key is, the harder it is to break the encryption.