Using Encryption Techniques

Symmetric cryptography

Symmetric cryptography, also called private-key cryptography, uses a single key to both encrypt and decrypt a message. This method is generally inappropriate for securing data that is expected to be utilized by a third party, due to the complexity of secure key exchange. Symmetric cryptography is generally useful for encrypting data for one's own purposes.

A classic use of symmetric cryptography is for a personal password vault. Anyone who has been using the Internet for any amount of time has accumulated a quantity of user names and passwords for accessing various sites and resources. A personal password vault lets you store this access information in an encrypted form. The end result is that you only have to remember one password to unlock all of your access information.

Until recently, the United States government was standardized on a symmetric encryption algorithm called DES (Data Encryption Standard) to secure important information. Because there is no direct way to crack DES encrypted data, to decrypt DES encrypted data without a password you would have to use an unimaginable amount of computing power to try to guess the password. This is also known as the brute force method of decryption.

As personal computing power has increased nearly exponentially, the DES algorithm has had to be retired. In its place, after a very long and interesting search, the United States. government has accepted the Rijndael algorithm as what it calls the AES (Advanced Encryption Standard). Although the AES algorithm is also subject to brute force attacks, it requires significantly more computing power to crack than the DES algorithm does.

For more information on AES, including a command line implementation of the algorithm, you can visit http://aescrypt.sourceforge.net/.

Public-key cryptography

Public-key cryptography does not suffer from key distribution problems, and that is why it is the preferred encryption method for secure Internet communication. This method uses two keys, one to encrypt the message and another to decrypt the message. The key used to encrypt the message is called the public key because it is made available for all to see. The key used to decrypt the message is the private key and is kept hidden. The entire process works like this:

Imagine that you want to send me a secure message using public-key encryption. Here is what we need:

1. I must have a public and private key pair. Depending on the circumstances, I may generate the keys myself (using special software) or obtain the keys from a key authority.

2. You wish to send me a message, so you first look up my public key (or more accurately, the software you are using looks it up).

3. You encrypt the message with the public key. At this point, the message can only be decrypted with the private key (the public key cannot be used to decrypt the message).

4. I receive the message and use my private key to decrypt it.

Secure Socket Layer

A classic implementation of public-key cryptography is with SSL (secure socket layer) communication. This is the technology that enables you to securely submit your credit card information to an online merchant. The elements of an SSL encrypted session are as follows:

• SSL Enabled Web Browser (Mozilla, Internet Explorer, Opera, Konquerer, etc.)

• SSL Enabled Web Server (Apache)

• SSL Certificate

To initiate an SSL session, a Web browser first makes contact with a Web server on port 443, also known as the HTTPS port (Hypertext Transport Protocol Secure). Once a socket connection has been established between the two machines, the following occurs:

1. Server sends SSL certificate to browser.

2. Browser verifies identity of server through SSL certificate.

3. Browser generates symmetric encryption key.

4. Browser uses SSL certificate to encrypt symmetric encryption key.

5. Browser sends encrypted key to the server.

6. Server decrypts the symmetric key with its private key counterpart of the public SSL certificate.

7. Browser and server can now encrypt and decrypt traffic based on a common knowledge of the symmetric key.

Secure data interchange can now occur.

Creating SSL Certificates

In order to create your own SSL certificate for secure HTTP data interchange, you must first have an SSL-capable Web server. The Apache Web server (httpd package), which comes with Red Hat Linux, is SSL-capable. Once you have a server ready to go, you should familiarize yourself with the important server-side components of an SSL certificate:

# ls -l /etc/httpd/conf
drwxr-xr-x     7 root     root     4096 Aug 12 23:45 .
drwxr-xr-x  4 root     root      4096 Aug 13 00:23 ..
-rw-r--r--  1 root     root      35918 Jul 14 15:45 httpd.conf
lrwxrwxrwx  1 root     root      37 Aug 12 23:45 Makefile ->
../../../usr/share/ssl/certs/Makefile
drwx------  2 root     root      4096 Aug 12 23:45 ssl.crl
drwx------  2 root     root      4096 Aug 12 23:45 ssl.crt
drwx------  2 root     root      4096 Jul 14 15:45 ssl.csr
drwx------  2 root     root      4096 Aug 12 23:45 ssl.key
drwx------  2 root     root      4096 Jul 14 15:45 ssl.prm
   
# ls -l /etc/httpd/conf.d/ssl.conf
-rw-r--r--  1 root     root      11140 Jul 14 15:45 ssl.conf

The /etc/httpd/conf and /etc/httpd/conf.d directories contains all of the components necessary to create your SSL certificate. Each component is defined as follows:

• httpd.conf — Web server configuration file.

• Makefile — Certificate building script.

• ssl.crl — Certificate revocation list directory.

• ssl.crt — SSL certificate directory.

• ssl.csr — Certificate service request directory.

• ssl.key — SSL certificate private key directory.

• ssl.prm — SSL certificate parameters.

• ssl.conf — Primary Web server SSL configuration file.

Now that you're familiar with the basic components, take a look at the tools used to create SSL certificates:

# cd /etc/httpd/conf
# make
This makefile allows you to create:
  o public/private key pairs
  o SSL certificate signing requests (CSRs)
  o self-signed SSL test certificates
   
To create a key pair, run "make SOMETHING.key".
To create a CSR, run "make SOMETHING.csr".
To create a test certificate, run "make SOMETHING.crt".
To create a key and a test certificate in one file, run "make
SOMETHING.pem".
   
To create a key for use with Apache, run "make genkey".
To create a CSR for use with Apache, run "make certreq".
To create a test certificate for use with Apache, run "make testcert".
   
Examples:
  make server.key
  make server.csr
  make server.crt
  make stunnel.pem
  make genkey
  make certreq
  make testcert

The make command utilizes the Makefile to create SSL certificates. Without any arguments the make command simply prints the information listed above. The following defines each argument you can give to make:

• make server.key — Creates generic public/private key pairs.

• make server.csr — Generates a generic SSL certificate service request.

• make server.crt — Generates a generic SSL test certificate.

• make stunnel.pem — Generates a generic SSL test certificate, but puts the private key in the same file as the SSL test certificate.

• make genkey — Same as make server.key except it places the key in the ssl.key directory.

• make certreq — Same as make server.csr except it places the certificate service request in the ssl.csr directory.

• make testcert — Same as make server.crt except it places the test certificate in the ssl.crt directory.

Using third-party certificate signers

In the real world, I know who you are because I recognize your face, your voice and your mannerisms. On the Internet, I cannot see these things and must rely on a trusted third party to vouch for your identity. To ensure that a certificate is immutable, it has to be signed by a trusted third party when the certificate is issued and validated every time an end user taking advantage of your secure site loads it. The following is a list of the trusted third-party certificate signers:

• GlobalSign — https://www.globalsign.net/

• Baltimore — https://www.baltimore.com/

• GeoTrust — https://www.geotrust.com/

• VeriSign — https://www.verisign.com/

• FreeSSL — http://www.freessl.com/

• Thawte — http://www.thawte.com/

• EnTrust — http://www.entrust.com/

• ipsCA — http://www.ipsca.com/

• COMODO Group — http://www.comodogroup.com/

Each of these certificate authorities has gotten a chunk of cryptographic code embedded into nearly every Web browser in the world. This chunk of cryptographic code allows a Web browser to determine whether or not an SSL certificate is authentic. Without this validation, it would be trivial for crackers to generate their own certificates and dupe people into thinking they are giving sensitive information to a reputable source.

Certificates that are not validated are called self-signed certificates. If you come across a site that has not had its identity authenticated by a trusted third party, your Web browser will display a message similar to the one shown in Figure 14-4.

Figure 14-4: A pop-up window alerts you when a site is not authenticated.

This does not necessarily mean that you are encountering anything illegal, immoral or fattening. Many sites opt to go with self-signed certificates, not because they are trying to pull a fast one on you, but because there may not be any reason to validate the true owner of the certificate and they do not wish to pay the cost of getting a certificate validated. Some reasons for a using a self-signed certificate include:

• The Web site accepts no input.???In this case, you as the end user, have nothing to worry about. There is no one trying to steal your information because you aren't giving out any information. Most of the time this is done simply to secure the Web transmission from the server to you. The data in and of itself may not be sensitive, but, being a good netizen, the site has enabled you to secure the transmission to keep third parties from sniffing the traffic.

• The Web site caters to a small clientele.???If you run a Web site that has a very limited set of customers, such as an Application Service Provider, you can simply inform your users that you have no certificate signer and that they can browse the certificate information and validate it with you over the phone or in person.

• Testing.???It makes no sense to pay for an SSL certificate if you are only testing a new Web site or Web-based application. Use a self-signed certificate until you are ready to go live.

Creating a Certificate Service Request

To create a third party validated SSL certificate, you must first start with a CSR (Certificate Service Request). To create a CSR, do the following on your Web server:

# cd /etc/httpd/conf
# make certreq
umask 77 ; \
/usr/bin/openssl genrsa -des3 1024 > /etc/httpd/conf/ssl.key/server.key
    .
    .
    .

You will now be asked to enter a password to secure your private key. This password should be at least eight characters long, and should not be a dictionary word or contain numbers or punctuation. The characters you type will not appear on the screen, in order to prevent someone from shoulder surfing your password.

Enter pass phrase:

Enter the password once again to verify.

Verifying - Enter pass phrase:

The certificate generation process now begins.

At this point, it is time to start adding some identifying information to the certificate that the third party source will later validate. Before you can do this, you must unlock the private key you just created. Do so by typing the password you typed above. Then enter information as you are prompted. An example of a session for adding information for your certificate is shown below:

Enter pass phrase for /etc/httpd/conf/ssl.key/server.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called
a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]: Connecticut
Locality Name (eg, city) [Newbury]: Mystic
Organization Name (eg, company) [My Company Ltd]:Acme Marina, Inc.
Organizational Unit Name (eg, section) []:InfoTech
Common Name (eg, your name or your server's hostname)
[]:www.acmemarina.com
Email Address []: webmaster@acmemarina.com

To complete the process, you will be asked if you want to add any extra attributes to your certificate. Unless you have a reason to provide more information, you should simply hit enter at each of the following prompts to leave them blank.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Getting the CSR Signed

Once your CSR has been created, you now need to send it to a signing authority for validation. The first step in this process is to select a signing authority. Each signing authority has different deals, prices and products. Check out each of the signing authorities listed in the "Using third-party certificate signers" section above to determine which works best for you. The following are areas where signing authorities differ:

• Credibility and stability

• Pricing

• Browser recognition

• Warranties

• Support

• Certificate strength

For good comparisons, studies and inside information to make the job of finding an SSL signer easier, go to http://www.whichssl.org.

Once you have selected your certificate signer, you will have to go through some validation steps. Each signer has a different method of validating identity and certificate information. Some require that you fax articles of incorporation, while others require a company officer be made available to talk to a validation operator. At some point in the process you will be asked to copy and paste the contents of the CSR you created into the signer's Web form.

# cd /etc/httpd/conf/ssl.csr
# cat server.csr
-----BEGIN CERTIFICATE REQUEST-----
MIIB6jCCAVMCAQAwgakxCzAJBgNVBAYTAlVTMRQwEgYDVQQIEwtDb25uZWN0aWN1
dDEPMA0GA1UEBxMGTXlzdGljMRowGAYDVQQKExFBY21lIE1hcmluYSwgSW5jLjER
MA8GA1UECxMISW5mb1RlY2gxGzAZBgNVBAMTEnd3dy5hY21lbWFyaW5hLmNvbTEn
MCUGCSqGSIb3DQEJARYYd2VibWFzdGVyQGFjbWVtYXJpbmEuY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDcYH4pjMxKMldyXRmcoz8uBVOvwlNZHyRWw8ZG
u2eCbvgi6w4wXuHwaDuxbuDBmw//Y9DMI2MXg4wDq4xmPi35EsO1Ofw4ytZJn1yW
aU6cJVQro46OnXyaqXZOPiRCxUSnGRU+0nsqKGjf7LPpXv29S3QvMIBTYWzCkNnc
gWBwwwIDAQABoAAwDQYJKoZIhvcNAQEEBQADgYEANv6eJOaJZGzopNR5h2YkR9Wg
l8oBl3mgoPH60Sccw3pWsoW4qbOWq7on8dS/++QOCZWZI1gefgaSQMInKZ1II7Fs
YIwYBgpoPTMC4bp0ZZtURCyQWrKIDXQBXw7BlU/3A25nvkRY7vgNL9Nq+7681EJ8
W9AJ3PX4vb2+ynttcBI=
-----END CERTIFICATE REQUEST-----

You can use your mouse to copy and paste the CSR into the signer's Web form.

Once you have completed the information validation, paid for the signing and answered all of the questions, you have completed most of the process. Within 48 to 72 hours you should receive an e-mail with your shiny new SSL certificate in it. The certificate will look similar to the following:

-----BEGIN CERTIFICATE-----
MIIEFjCCA3+gAwIBAgIQMI262Zd6njZgN97tJAVFODANBgkqhkiG9w0BAQQFADCB
ujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVy
aVNpZ24sIEluXy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2Vy
dmVyIENBIC0gZ2xhc3MgMzFJMEcG10rY2g0Dd3d3LnZlcmlzaWduLmNvbS9DUFMg
SW5jb3JwLmJ51FJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0w
MzAxMTUwMDAwMDBaFw0wNDAxMTUyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzETMBEG
A1UECBMKV2FzaG1uZ3RvHiThErE371UEBxQLRmVkZXJhbCBXYXkxGzAZBgNVBAoU
EklETSBTZXJ2aWMlcywgSW5jLjEMMAoGA1UECxQDd3d3MTMwMQYDVQQLFCpUZXJt
cyBvZiB1c2UgYXQgd3d3LnZlcmlzawduLmNvbS9ycGEgKGMpMDAxFDASBgNVBAMU
C2lkbXNlcnYuY29tMIGfMA0GCSqGS1b3DQEBAQUAA4GNADCBiQKBgQDaHSk+uzOf
7jjDFEnqT8UBa1L3yFILXFjhj3XpMXLGWzLmkDmdJjXsa4x7AhEpr1ubuVNhJVI0
FnLDopsx4pyr4n+P8FyS4M5grbcQzy2YnkM2jyqVF/7yOW2pDl30t4eacYYaz4Qg
q9pTxhUzjEG4twvKCAFWfuhEoGu1CMV2qQ1DAQABo4IBJTCCASEwCQYDVR0TBAIw
ADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCOwKAYIKwYBBQUHAgEWHGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVRRPBAQDAgWgMCgGA1UdJQQhMB8G
CWCGSAGG+EIEM00c0wIYBQUHAwEGCCsGAQUFBwmCMDQGCCsGAQUFBwEBBCgwJjAk
BggrBgEFBQcwAYYYaHR0cDovL29jc2AudmVyaXNpZ24uY29tMEYGA1UdHwQ/MD0w
O6A5oDeGNWh0dHA6Ly9jcmwudmVyaxNpZ24uY29tL0NsYXNzM0ludGVybmF0aW9u
YWxTZXJ2ZXIuY3JsMBkGCmCGSAgG+E+f4Nfc3zYJODA5NzMwMTEyMA0GCSqGSIb3
DQEBBAUAA4GBAJ/PsVttmlDkQai5nLeudLceb1F4isXP17B68wXLkIeRu4Novu13
8lLZXnaR+acHuCkW01b3rQPjgv2y1mwjkPmC1WjoeYfdxH7+Mbg/6fomnK9auWAT
WF0iFW/+a8OWRYQJLMA2VQOVhX4znjpGcVNY9AQSHm1UiESJy7vtd1iX
-----END CERTIFICATE-----

Copy and paste this certificate into an empty file called server.crt, which must reside in the /etc/httpd/conf/ssl.crt directory, and restart your Web server:

# service httpd restart

Assuming your Web site was previously working fine, you can now view it in a secure fashion by placing an "s" after the http in the Web address. So if you previously viewed your Web site at http://www.acmemarina.com, you can now view it in a secure fashion by going to https://www.acmemarina.com.

You are about to be asked to enter information that will be
  incorporated into your certificate request.
What you are about to enter is what is called
a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]: Ohio
Locality Name (eg, city) [Newbury]: Cincinnati
Organization Name (eg, company) [My Company Ltd]:Industrial Press, Inc.
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server's hostname)
[]:www.industrialpressinc.com
Email Address []: webmaster@industrialpressinc.com

# cd /etc/httpd/conf/ssl.key
# /usr/bin/openssl rsa -in server.key -out  server.key

Exporting encryption technology

Before describing how to use the various encryption tools, I need to warn you about an unusual policy of the United States government. For many years, the United States government treated encryption technology like munitions. As a result, anyone wishing to export encryption technology had to get an export license from the Commerce Department. This applied not only to encryption software developed within the United States, but also to software obtained from other countries and then re-exported to another country (or even to the same country you got it from). Thus, if you installed encryption technology on your Linux system and then transported it out of the country, you were violating federal law! Furthermore, if you e-mailed encryption software to a friend in another country or let him or her download it from your server, you violated the law.

In January 2000, U.S. export laws relating to encryption software were relaxed considerably. However, often the U.S. Commerce Department's Bureau of Export Administration requires a review of encryption products before they can be exported. U.S. companies are also still not allowed to export encryption technology to countries classified as supporting terrorism.

Using the Secure Shell package

The Secure Shell package (SSH) is a package that provides shell services similar to the rsh, rcp, and rlogin commands, but encrypts the network traffic. It uses Private-Key Cryptography, so it is ideal for use with Internet connected computers. The Red Hat Linux distribution contains the following client and server software packages for SSH: openssh, openssh-client, and openssh-server packages.

Starting the SSH service

If you have installed the openssh-server software package, the SSH server is automatically configured to start. The SSH daemon is started from the /etc/init.d/sshd start-up script. To make sure the service is set up to start automatically, type the following (as root user):

# chkconfig --list sshd
sshd      0:off   1:off   2:on   3:on   4:on   5:on   6:off

This shows that the sshd service is set to run in system states 2, 3, 4, and 5 (normal bootup states) and set to be off in all other states. You can turn on the SSH service, if it is off, for your default run state, by typing the following as root user:

# chkconfig sshd on

This line turns on the SSH service when you enter run levels 2, 3, 4, or 5. To start the service immediately, type the following:

# /etc/init.d/sshd start

Using the ssh, sftp, and scp commands

Three commands you can use with the SSH service are ssh, sftp, and scp. Remote users use the ssh command to login to your system securely. The scp command lets remote users copy files to and from a system. The sftp command provides a safe way to access FTP sites.

Like the normal remote shell services, secure shell looks in the /etc/hosts.equiv file and in a user's .rhost file to determine whether it should allow a connection. It also looks in the ssh-specific files /etc/shosts.equiv and .shosts. Using the shosts.equiv and the .shosts files is preferable because it avoids granting access to the nonencrypted remote shell services. The /etc/shosts.equiv and .shosts files are functionally equivalent to the traditional hosts.equiv and .rhosts, so the same instructions and rules apply.

Now you are ready to test the SSH service. From another computer on which SSH has been installed (or even from the same computer if another is not available), type the ssh command followed by a space and the name of the system you are connecting to. For example, to connect to the system ratbert.glaci.com, type:

# ssh ratbert.glaci.com

If this is the first time you have ever logged in to that system using ssh, it will ask you to confirm that you really want to connect. Type yes and press Enter when it asks this:

Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?

It should then prompt you for a user name and password in the normal way. The connection will then function like a normal telnet connection. The only difference is that the information is encrypted as it travels over the network. You should now also be able to use the ssh command to run remote commands.

The scp command is similar to the rcp command for copying files to and from Linux systems. Here is an example of using the scp command to copy a file called memo from the home directory of the user named jake to the /tmp directory on a computer called maple:

$ scp /home/jake/memo maple:/tmp
passwd: ********
memo       100%|****************|  153   0:00

Enter the password for your user name (if a password is requested). If the password is accepted, the remote system indicates that the file has been copied successfully.

Similarly, the sftp command starts an interactive FTP session with an FTP server that supports SSH connections. Many security-conscious people prefer sftp to other ftp clients because it provides a secure connection between you and the remote host. Here's an example:

$ sftp ftp.handsonhistory.com
Connecting to ftp.handsonhistory.com
passwd: ********
sftp>

At this point you can begin an interactive FTP session. You can use get and put commands on files as you would using any FTP client, but with the comfort of knowing that you are working on a secure connection.

Using ssh, scp and sftp without passwords

For machines that you use a great deal, it is often helpful to set them up so that you do not have to use a password to log in. The following procedure shows you how to do that.

These steps will take you through setting up password-less authentication from one machine to another. In this example, the local user is named chuckw on a computer named host1. The remote user is also chuckw on a computer named host2.

1. Log in to the local computer (in this example, I log in as chuckw to host1).

   Note?

   Only run step 2 once as local user on your local workstation. Do not run it again unless you lose your ssh keys. When configuring subsequent remote servers, skip right to step 3.

2. Type the following to generate the ssh key:

   $ ssh-keygen -t dsa
   

3. Accept the defaults by pressing Enter at each request.

4. Type the following to copy the key to the remote server (replace chuckw with the remote user name and host2 with the remote host name):

   $ cd ~/.ssh
   $ scp id_dsa.pub chuckw@host2:/tmp
   chuckw@host2's password: *******
   

5. Type the following to add the ssh key to the remote-user's authorization keys:

   $ ssh chuck2@host2 'cat /tmp/id_dsa.pub >> /home/chuckw/.ssh/authorized_keys2'

   Note?

   Steps 3 and 4 will ask for passwords. This is okay.

6. Type the following to remove the key from the temporary directory:

   $ ssh chuckw@host2 /bin/rm /tmp/id_dsa.pub
   

   Note?

   Step 5 should not ask for a password.

It is important to note that once you have this working, it will work regardless of how many times the IP address changes on your local computer. IP address has nothing to do with this form of authentication.