Encryption VI

Encrypting Linux Files

Just as you can encrypt network transmissions between Linux systems
using OpenSSH, you can also use encryption to protect files in the
Linux file system. You can use a wide variety of tools to do this.
Some are open source; others are proprietary. For your Linux+/LPIC-1
exam, you need to know how to use the open source GNU Privacy Guard
(GPG) utility to encrypt files. Therefore, that’s the tool we will use
here. We’ll discuss the following:


• How GPG works
• Using GPG to encrypt files
.


How GPG Works


GNU Privacy Guard (GPG) is an open source implementation of the
OpenPGP standard (RFC 4880). It allows you to encrypt and digitally
sign your data and communications. For example, you can encrypt files
in your Linux file system. You can also encrypt and digitally sign
e-mail messages.


GPG provides a cryptographic engine that can be used directly from the
shell prompt using the


gpg 


command-line utility. It can also be called from within shell scripts or other programs running on the system.


For example, GPG support has been integrated into several popular Linux
e-mail clients such as Evolution and KMail. It has also been
integrated into instant messaging applications such as Psi.


A variety of graphical front ends are available for GPG as well. Some
of the more popular front ends include KGPG and Seahorse. However, for
your Linux+/LPIC-1 exam, you need to know how to use GPG from the
shell prompt, so that’s what we’ll focus on in this chapter.


GPG functions in a manner similar to OpenSSH in that it uses both
asymmetric and symmetric cryptography. 


a) GPG first generates a random symmetric key and uses it to encrypt the message to be transferred.


b) The symmetric key itself is then encrypted using the recipient’s
    public key and sent along with the message that was encrypted using
    the symmetric key.


c) When the recipient receives a message, GPG first decrypts the symmetric key 
    using the user’s private key. GPG then uses the decrypted symmetric key to decrypt 
    the rest of the message.



GPG supports many encryption algorithms, including the following:


Symmetric encryption:
• AES
• 3DES
• Blowfish


Asymmetric encryption:
• Elgamal
• RSA

Hashes:
• MD5
• SHA-1 and -2 
• RIPEMD-160

Digital signatures:
• DSA
• RSA


Now that you understand how GPG works, let’s review how you can use
GPG to encrypt files.


Using GPG to Encrypt Files

To encrypt a file using GPG, do the following:

1. Use GPG to generate your keys. To do this, enter

gpg --gen-key

at the shell prompt. An example is shown here:


      rtracy@openSUSE:~> gpg --gen-key
      gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
      Please select what kind of key you want:
         (1) RSA and RSA (default)
         (2) DSA and Elgamal
         (3) DSA (sign only)
         (4) RSA (sign only)
      Your selection?


2. Select the type of key you want to create. Usually you will use the
default option (1), which uses RSA and RSA. You are prompted to
specify the size of the key, as shown here:


      RSA keys may be between 1024 and 4096 bits long.
      What keysize do you want? (2048)


3. Specify the size of key you want to create. Using the default size
of 2048 bits is usually sufficient. You are prompted to configure the
key lifetime, as shown here:


      Please specify how long the key should be valid.
               0 = key does not expire
            <n>  = key expires in n days
            <n>w = key expires in n weeks
            <n>m = key expires in n months
            <n>y = key expires in n years
      Key is valid for? (0)


4. Specify when the key will expire. As shown in step 3, you can
specify that the key expire in a certain number of days, weeks,
months, or years.


5. Construct your user ID for the key. The first parameter you need to
specify is your real name. The name you specify is very important
because it will be used later during the encryption process. In the
next example, I entered rtracy for my real name:


      GnuPG needs to construct a user ID to identify your key.
      Real name: rtracy


6. When prompted, enter your e-mail address.


7. When prompted, enter a comment of your choosing. You are prompted
to confirm the user ID you have created for the key. An example is
shown here:


       You selected this USER-ID:
           "rtracy <rtracy@openSUSE>"
       Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?


8. If the information is correct, enter O to confirm the ID. You are
prompted to enter a passphrase for the key, as shown in Figure 18-10.


9. Enter a unique passphrase for the key. After doing so, you are
prompted to perform various actions on the system while the key is
generated. An example is shown here:


       We need to generate a lot of random bytes. It is a good idea to perform
       some other action (type on the keyboard, move the mouse, utilize the
       disks) during the prime generation; this gives the random number
       generator a better chance to gain enough entropy.
       .+++++.++++++++++++++++++++++++++++++.+++++.++++++++++++++++++++++++++++++++
       +++.++++++++++.++++++++++.++++++++++.++++++++++..+++++.++++++++++>++++++++++
       ...................................>+++++............................<+++++.
       ................................>+++++...........<+++++.......+++++


10. Move the mouse, type characters on your keyboard, or open and
close your optical disc drive door. GPG uses these actions to generate
random numbers to create your key. Be aware that if you’re not doing
enough, you’ll be prompted to increase your activity to generate
enough entropy to create the key. An example is shown here:


       Not enough random bytes available.  Please do some other work to give
       the OS a chance to collect more entropy! (Need 137 more bytes)



At this point, your key pair has been generated! The key files are
stored in the


~/.gnupg 


directory in your user’s home directory. The following files are created in this directory:

• secring.gpg   This file is the GPG secret keyring.

• pubring.gpg   This file is the GPG public keyring.

• trustdb.gpg   This file is the GPG trust database.




Before going any further, you should seriously consider creating a
backup of your private key in case it gets corrupted. This is very
important because if you encrypt files with your key pair and then
lose your key, you will never be able to decrypt them. They are toast!
Even if you re-create  your key pair, you will not be able to decrypt
the files because they were encrypted with a different key pair.



To create a backup of your gpg key pair, enter



gpg --export-secret-keys --armor key_owner_ email_address > filename.asc



at the shell prompt. This is shown in the following example:


gpg --export-secret-keys --armor rtracy@openSUSE >
rtracy-privatekey.asc rtracy@openSUSE:~> ls
addnum firstnames mytestfile.txt rtracy-privatekey.asc


For security reasons, you probably shouldn’t leave this file on your
hard disk. Instead, consider burning it to an optical disc or copying
it to a USB flash drive and locking it away in a file cabinet
somewhere. This will allow you to restore your private key should the
original copy on the hard drive get mangled.


You can now use your key pair to encrypt files and messages. For
example, if you wanted to encrypt a file in your Linux file system,
you would do the following:


1. At the shell prompt, enter

gpg –e –r key_user_name filename

In the example shown here, I’m encrypting the mytestfile.txt file
using the key I generated previously. The –e option tells gpg to
encrypt the specified file. Remember that I specified a key username
of rtracy when I created the key user ID, so that’s what I entered
here.

      rtracy@openSUSE:~> gpg -e -r rtracy mytestfile.txt

2. At the shell prompt, use the ls command to view the new encrypted
version of the file gpg created. The original file is left intact.


The new file will have the same filename as the original file with a“.gpg” extension added. 


In the example here, the name of the new file is mytestfile.txt.gpg. 


In Figure 18-11, the differences between the
original file and the encrypted file are shown.


Once the file has been encrypted, it can then be decrypted using the
gpg command. The syntax is



gpg --output output_filename --decrypt encrypted_filename



For example, to decrypt  the mytestfile.txt.gpg file I created
earlier, I would enter



gpg --output mytestfile.txt.decrypted --decrypt mytestfile.txt.gpg



This is shown in the example here:



rtracy@openSUSE:~> gpg --output mytestfile.txt.decrypted --decrypt mytestfile.txt.gpg


You need a passphrase to unlock the secret key for

user: "rtracy (<rtracy@openSUSE>"
2048-bit RSA key, ID FB8BF16C, created 2015-01-24 (main key ID 9DF54AB2)
gpg: encrypted with 2048-bit RSA key, ID FB8BF16C, created 2015-01-24
      "rtracy (<rtracy@openSUSE>"
rtracy@openSUSE:~> cat mytestfile.txt.decrypted
This is a text file that I wrote.
rtracy@openSUSE:~>


At this point, you are able to encrypt and decrypt files on your local
system.


But what do you do if you want to be able to exchange
encrypted files with someone else and both of you be able to decrypt them? 


To do this, you must exchange and install gpg public keys on your systems. There are two ways to do this.


The first option is to copy your public keys to a public key server on
the Internet. This is done by entering


gpg --keyserver hkp://subkeys.pgp.net --send-key key_ID



at the shell prompt. Notice that this command requires you to know the
ID number associated with your gpg public key. This number is actually
displayed when you initially create your gpg key pair, but if you’re
like me, you probably didn’t take note of it. That’s not a problem
because you can generate it again from the command line. To do this,
enter


gpg --fingerprint key_owner_email

An example is shown here:

rtracy@openSUSE:~> gpg --fingerprint rtracy@openSUSE > key_ID.txt
rtracy@openSUSE:~> cat key_ID.txt
pub  2048R/9DF54AB2 2015-01-24
     Key fingerprint = AF46 4AB3 1397 B88E BC6A FBDA 465F 82C4 9DF5 4AB2
uid    rtracy       <rtracy@openSUSE>

sub  2048R/FB8BF16C 2015-01-24




In this example, I actually saved the output from the command to afile named key_ID.txt to keep it handy, but this is optional. The ID
number of the key is contained in the first line of output from the
command. Note that I’ve bolded the number needed.


Once you have the ID number, you can then copy your gpg public key to
a public key server on the Internet. Using the preceding information
for my system, I would enter



gpg --keyserver hkp://subkeys.pgp.net --send-key 9DF54AB2



at the command prompt.




This option works great if you want to be able to exchange keys with a
large number of other users.





However, if you are only concerned about doing this with a limited number of people, you can also just directly exchange keys between systems.


To do this, you (and the other users) can export your public keys and
send them to each other. To do this, you enter



gpg --export --armor key_owner_email > public_key_filename



at the shell prompt.



For example, to export the public key to a file named gpg.pub from the
key pair I created earlier, I would enter the following:


rtracy@openSUSE:~> gpg --export rtracy@openSUSE > gpg.pub




Each user can then copy their key file to the other users. For
example, if I wanted to send my key to the student user account on
another Linux host named fedora, I would enter the following:

rtracy@openSUSE:~> scp gpg.pub student@fedora:

Once this is done, each user should import the other users’ public
keys into their GPG keyring using the



gpg --import public_key_filename



command at the shell prompt. In the example shown next, I first used
scp to copy the public key file from the openSUSE system to the fedora
system. I then used gpg to import the public key.



[student@fedora ~]$ gpg --import gpg.pub
gpg: key 9DF54AB2: public key "rtracy <rtracy@openSUSE>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
[student@fedora ~]



Remember, each user needs to repeat this process. Then they can use
each other’s gpg keys to encrypt and decrypt files.




You can view the keys in your GPG keyring using the


gpg --list-keys



command, as shown in the following example:

[student@fedora ~]$ gpg --list-keys
/home/student/.gnupg/pubring.gpg
--------------------------------

pub   2048R/9DF54AB2 2015-01-24
uid   rtracy <rtracy@openSUSE>
sub   2048R/FB8BF16C 2015-01-24
[student@fedora ~]$



In this example, you can see that the public key I created earlier on
openSUSE is now imported into the student user’s GPG keyring on
fedora.




The keyring file itself is located in the 


~/.gnupg/ 


directory within my home directory and is named 


pubring.gpg


NOTE

The


gpg.conf 


file is also located in the 


~/.gnupg 


directory. You can use this file to customize the way gpg works on your system.


I would then need to do the same thing in reverse. I should import the
public key from the student user on the fedora system to my system
(openSUSE).


With the public keys imported, we could exchange encrypted files and be able to decrypt them. 

The syntax for doing this is



gpg --output output_filename --symmetric encrypted_filename




For example, if I sent the mytest- file.txt.gpg encrypted document
from my openSUSE system to my fedora system, I would enter the
following command to decrypt it



gpg --output mytestfile.txt.decrypted --symmetric  mytestfile.txt.gpg


When I do, I am prompted to enter the passphrase I assigned to the
private key when I initially generated it. Once this is done, the
decrypted version of the file is created and is accessible to the
local user.



Before we end this chapter, we need to discuss the topic of key
revocation. From time to time, you may need to revoke a key, which
withdraws it from public use. This should be done if the key becomes
compromised, gets lost, or if you forget the passphrase associated
with the key.


NOTE     Forgetting the passphrase associated with the key pair is a very
common problem that results in key revocation.



To revoke a key, you create a key revocation certificate. As a best
practice, you should create a key revocation certificate immediately
after initially creating your key pair. This is done in case something
gets corrupted and the revocation certificate can’t be created should
it be required for some reason later on. Here’s a key thing to
remember: creating the key revocation certificate doesn’t actually
revoke the key pair. Only when you actually issue the key revocation
certificate does the key get revoked. Basically, you create the key
revocation certificate and save it in a secure location just in case
it’s needed later.



To create (not issue) the key revocation certificate, enter



gpg --output revoke.asc --gen-revoke key_ID



at the shell prompt. Remember, you can use the


--fingerprint option


with the gpg command to view the key ID number. In the example that
follows, I create a key revocation certificate for the gpg key pair I
generated for the student user on my fedora system:



[student@fedora ~]$ gpg --fingerprint student@fedora
  pub
2048R/899AB9E6 2015-01-24
Key fingerprint = A469 942C F5C9 555A B4A4 F975 1B3A CB26 899A B9E6
uid
sub
[student@fedora ~]$ gpg --output revoke.asc --gen-revoke 899AB9E6
sec  2048R/899AB9E6 2015-01-24 student <student@fedora>
Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> This key has been compromised
>
Reason for revocation: Key has been compromised
This key has been compromised
Is this okay? (y/N) y
You need a passphrase to unlock the secret key for
user: "student <student@fedora>"
2048-bit RSA key, ID 899AB9E6, created 2015-01-24
ASCII armored output forced.
Revocation certificate created.
Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.



It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!

Notice in this example that I had to specify a reason why the key is
to be revoked along with a more detailed description. I also had to
provide the passphrase that was used when the key pair was originally
created. Also notice the warning message at the end of the command
output. You probably should avoid keeping the key revocation
certificate on your system’s hard disk. Instead, burn it to the same
optical disc or copy it to the same flash drive as your key pairbackup and lock it away! If someone were to get a hold of this file,
they could revoke your certificate without your knowledge or consent,
which would be a bad thing.


TIP     The output of the command says to print out the key revocation
certificate. I think that is a cumbersome way to archive it. If you
ever needed to issue it, you would have to type the revocation
certificate in manually.


Yuck! I much prefer copying it to a flash drive that I keep locked in a cabinet. Don’t forget to delete the file off the hard disk, no matter what archival mechanism you choose to use.


So what should you do if your certificate actually does get
compromised and you end up needing to revoke it? The process is
actually pretty easy. All you have to do is import the revocation
certificate in the same manner we talked about for standard
certificates. You enter gpg --import revocation_certificate_filename
at the shell prompt. An example is shown here:


[student@fedora ~]$ gpg --import revoke.asc
gpg: key 899AB9E6: "student <student@fedora>" revocation certificate imported
gpg: Total number processed: 1
gpg:    new key revocations: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u


Once this is done, you can verify that the key was revoked by entering



gpg --list-keys key_ID 


at the shell prompt. You should see that the revoked key is now gone from your keyring.
If you used the manual method discussed earlier in this chapter to distribute your public
key, you must import the key revocation certificate on any other
systems where your public key was imported.


If you are using a public key server on the Internet to distribute
your keys to other users, you would need to issue the key revocation
certificate there as well. Enter 



gpg --keyserver public_key_server_URL --send key_ID 



at the shell prompt. This lets everyone who is using your public key know that the key has been 
compromised and should no longer be used.




















LX0-104 Exam Objectives (X)