EncryptionTechnics

#

Data Encryption

Introduction

Cryptography ..... Storing your files in such a way that no-one except you can view the file, does have a lot of importance today. Cryptography consists of 2 types of algorithms Asymmetric and Symmetric.

Asymmetric encryption is based on the concept of Public and Private Key. On the other hand Symmetric encryption is based on a single 'Key' .

Hence it up to the person to first send the password to the receiver of the file so that he can decrypt it. In this example we learn how to use Symmetric encryption algorithms .


Symmetric file encryption – GnuPG

In the first example we will encrypt a single file using the gpg package. Here we will work on the file example.pdf.

Here the AES algorithm will be used (since it has the best performance to quality ratio). First we need to load the kernel module which will be responsible for handling it:

$ su -
$ modprobe aes
$ exit

We create the /home/forat/encrypted directory, in which we will store our encrypted data:

$ mkdir ~/encrypted

We save the example.pdf file in it.

Time for encryption. As we selected the file example.pdf, we issue the following command:

$ gpg --output ~/encrypted/cyph1 --symmetric --cipher-algo AES192 ~/encrypted/example.pdf

This command starts symmetric encryption of example.pdf to the output file ~/encrypted/cyph1 using the AES algorithm with a 192-bit key.

A password to the file needs to be set. We should think about a sentence which would be rather devoid of any sense, but easy to remember – for example, Big baboon sat at noon, mourning morning as it passed. What a ghast. It will be used it as a password.

The file has been encrypted. Now the original file needs to be safely wiped:

$ shred -n 35 -z -u ~/encrypted/example.pdf
  1. To decrypt the file and recover the data, we will use the following command:

    $ gpg --output example.pdf --decrypt ~/encrypted/cyph1


Encrypted directories – EncFS

Before using the EncFS tool, two directories need to be created. The first one (here: ~/.crypto) will store our files in the encrypted form (we will not use it directly), while the second one (~/secret) will be used to mount and decrypt them on-the-fly every time they need to be accessed. Mounting can be done only after entering the correct password.

$ mkdir ~/.crypto

$ mkdir ~/secret

In the next step the EncFS mechanism must be activated.

$ su -; insmod fuse; exit

$ encfs ~/.crypto ~/secret

After pressing the [Enter] key we will be asked to choose the configuration type. We decide to select the pre-configured paranoia mode.

Now it's time to enter the password for our archive. After we enter and confirm it, our file system is ready to use.

We copy several files to it (echo, ls, telnet):

$ cp /bin/echo /bin/ls /bin/telnet ~/secret/

Then we check what's inside~/secret and ~/.crypto directories:

$ ls ~/secret

$ ls ~/.crypto

It looks like our files are in the first directory and their encrypted version are in the second one. To hide their contents from everyone else, we can unmount the virtual file system by issuing this command:

$fusermount -u ~/crypto

We made it! Our data is secure now.

Let's now try to mount them again – this time with additional safeguard. The directory will be automatically unmounted after the specified period (10 minutes) of idle time:

$ encfs --idle=10 ~/.crypto ~/secret

Our files are available again in the ~/secret directory. After 10 minutes of waiting we will see that it is automatically unmounted.


Encrypted file system – cryptoloop

We still have one more tool which will help us to secure our files – a cryptoloop, which is included in the Linux kernel.

Let's assume that we don't have a free partition (which is the case with Hakin9 Live). Therefore we will use the very handy feature of the loopback mechanism, which allows us to use a single file as a filesystem. So now, let's prepare this file:

$ dd if=/dev/urandom of=~/crypto.raw bs=1k count=10000

This will create a 10 megabyte file filled with absolutely random content (i.e. junk).

The next step is to bind the created file with a free loop device and to encrypt it with a algorithm of choice:

$ su -

$ insmod cryptoloop

$ losetup -e aes-192 /dev/loop1 /home/haking/crypto.raw

The program will ask us for a password, which is a minimum of 20 characters long.

After we have prepared some space, it's time to tidy it up a little bit. We need to set up a filesystem there, which can be, for example, ext2:

$ mkfs.ext2 /dev/loop1

When it's done, we can free-up (-d option) the loop1 device:

$ losetup -d /dev/loop1

$ exit

Our encrypted filesystem is now ready to use, in exactly the same manner as any other filesystem would be. Let's mount it and see how it works:

$ mkdir ~/encrypted_disk

$ mount -t ext2 ~/crypto.raw ~/encrypted_disk -oencryption=aes-192

After we enter the correct password, mount will bind the specified file with the first free loop device.

Let's now copy our files to the safe container:

$ cp /bin/echo /bin/ls /bin/telnet ~/encrypted_disk

That's all – our new encrypted disk can be mounted and unmounted at will. Anyone who doesn't know the password will be unable to access it.


Encrypted file system dmcrypt

set up kernel

The stock debian 2.6 kernel-images seem to work fine. If you are compiling your own, these are what you must choose:

  • Code maturity level options --->
    • on: Prompt for development and/or incomplete code/drivers
  • General setup --->
    • on: Support for hot-pluggable devices
  • Device Drivers > Multi-device support (RAID and LVM).
    • on: Device mapper support
    • on: Crypt target support
  • Cryptographic options --->
    • on: AES cipher algorithms

The development driver prompts must be on, or you can't enable crypt target support for device mapper. Enabling support for hot-pluggable devices builds udev in the kernel, which makes things easier. If you enable udev, make sure you don't enable devfs.

After you are running the new kernel, test to make sure that the device mapper exists:

$ ls -L /dev/mapper/control

If you don't have the mapper device, installing the dmsetup package will create it for you.

Also check that AES is supported (or whatever cipher we choose to use):

$ cat /proc/crypto

$ should return: name : aes module : aes type : cipher blocksize : 16 min keysize : 16 max keysize : 32

If you are running crypto as modules, then you won't see anything when you cat /proc/crypto until the module gets loaded. cryptsetup should load the modules it needs when it is run. If you want to manually load a module, using the stock 2.6.7 debian kernel, you would do this:

$ insmod /lib/modules/2.6.7-1-386/kernel/crypto/aes.ko

or just:

$ modprobe aes

install user space tools

dmsetup

Install dmsetup, the linux kernel Device Mapper userspace library:

$ apt-get install dmsetup

Installing this package will create the mapper devices if they don't already exist.

check that the crypt target is supported:

$ dmsetup targets
crypt            v1.0.0
striped          v1.0.1
linear           v1.0.1
error            v1.0.1

(if using a module based kernel, it will be loaded when needed).

cryptsetup

cryptsetup is a tool to make it easier to use dm-crypt, so that you don't have to make dmsetup calls directly.

$ apt-get install cryptsetup

encrypted partitions

This is instructions for using dm-crypt to create a filesystem in a partition. See below for how to do set up dm-crypt with a loopback file instead.

creating the encrypted partition

It is a three step process to create our encrypted partition:

  1. run cryptsetup on the partition, which creates a device mapper device with target 'crypt'.
  2. create the file system on our new device.
  3. mount our new device.

In our example, we will be turning the physical volume /dev/sda9 into the logical volume (encrypted) at /dev/mapper/maildir (ie label is 'maildir') and then mounting it at /var/maildir.

create logical volume (with cryptsetup binary):

$ cryptsetup -y create maildir /dev/sda9a

or create logical volume (with cryptsetup script which comes with hashalot package):

$ cryptsetup -c aes -h ripemd160 -s 32 create maildir /dev/sda9

confirm it worked:

$ dmsetup ls
maildir (254, 0)

create filesystem:

$ mkfs.reiserfs /dev/mapper/maildir

mount filesystem:

$ mount /dev/mapper/maildir /var/maildir

real world usage

Every time we restart, we need to re-run the cryptsetup command and enter the same password. If we enter the wrong password, the encrypted device created won't be mountable and we need to destroy it and try again. Don't worry: as long as we don't reformat the device created with the wrong password, no data will be lost.

There are two ways we can do all this: on boot, or by manually running a script

on boot way

You can edit fstab to have /dev/mapper/maildir mounted to /var/maildir. This will only work if cryptsetup is run before partitions are read from fstab.

/etc/init.d/cryptinit:

if [ -b /dev/mapper/home ]; then
  /usr/bin/cryptsetup remove home
fi
/usr/bin/cryptsetup create home /dev/sda9

$ cd/etc/rcS.d
$ ln -s ../init.d/cryptinit S08cryptinit

manually

just run this script to get the partition up:

if [ -b /dev/mapper/maildir ]; then
  /usr/bin/cryptsetup remove maildir
fi
/usr/bin/cryptsetup create maildir /dev/sda9
mount /dev/mapper/maildir /var/maildir

dmcrypt home partitions

to have pam mount your encrypted home partition automatically at login, make these changes:

$ apt-get install libpam-mount cryptsetup openssl

add this to the end of /etc/pam.d/common-auth

auth    optional        pam_mount.so use_first_pass

add this to the end of /etc/pam.d/common-session

session optional        pam_mount.so

(alternately, you can add "@include common-pammount" to the end of common-auth & common-session).

add this to /etc/security/pam_mount.conf:

volume elijah crypt - /dev/hda4 /home/elijah cipher=aes aes-256-ecb /home/elijah.key

(in this case, 'elijah' is the username).

create /home/elijah.key:

$ echo "my dmcrypt password" | openssl aes-256-ecb > /home/elijah.key

(this is not a good idea because then your password is in your history file!) This will prompt you for a password. you must enter your login password. This command will encrypt your dmcrypt password (used to mount the dmcrypt partition) with your login password. When you login, pam-mount uses your login password to decrypt the .key file, then uses the password in the .key file to mount your home directory.

Alternately, if the login password and the dmcrypt password are the same, your line in /etc/security/pam_mount.conf would look like this:

volume elijah crypt - /dev/hda4 /home/elijah cipher=aes - -

edit /etc/login.def:

CLOSE_SESSIONS yes

(otherwise your encrypted partition will not be umounted when you logout).

if running sarge or older, you need to add symlink /sbin/mount.crypt -> /usr/bin/mount.crypt so that mount -t crypt actually works (debian bug: #267285).

Your home can be a loopback file. Follow the normal loopback directions, and specify this in /etc/security/pam_mount.conf:

volume elijah crypt - /home/home.img /home/elijah loop,cipher=aes aes-256-ecb /home/home.key

The only difference from using a real partition is that our source device is the loopback file name, and we add 'loop' to our list of options.


Network Layer Encryption

Introduction

All network encryption packages described in this document work on the same basis: A private network, which should be inaccessible to the outside world, is spread over many (physical) locations (read: company centres and/or roaming users) that are connected via the "evil" internet. This setup is commonly called VPN (virtual private network), because the private network shares its physical structure with the "real" internet.

The task is to route IP packets originating in the private network and destined for other hosts in the private network through the internet while preserving privacy.

This section describes problems and concepts common to all of the VPN packages to be described later on.

What are IP Tunnels?

The basic networking protocol nowadays is TCP/IP, mostly because it is the protocol the internet uses. But there were other network protocols and ever will be. When the internet began to grow, everyone was tempted to switch to the TCP/IP protocol, regardless of what he was using before. But many applications were not TCP/IP aware and it proved difficult to convert certain subnets to TCP/IP. However, one still wanted to benefit from the TCP/IP protocol and use it for communicating with the internet.

This was one major reason to invent tunnels. Just like TCP/IP packets are packed in Ethernet frames to send them over Ethernet or in PPP frames to send them over PPP links, one now wrappes TCP/IP packets with e.g. IPX frames to tunnel TCP/IP through IPX, or vice versa.

Thus, one was able to use TCP/IP in IPX or ATM---you name it---environments without fundamental changes to routers and so on.

The next picture shows an IP packet contained in an IPX frame:

 +------------++-----------+------------------+
 | IPX header || IP header |      payload     |
 +------------++-----------+------------------+
           <----- IP packet -------------->
 <----- IPX packet containing IP packet ------>

Of cource, no-one prevents you from tunneling IP packets in IP packets. While this does not seem very useful at first sight, there are indeed situations where this concept makes your network admin's life much easier.

One typical example of ordinary IP-in-IP tunneling is the connection of a roaming user to a LAN. The roaming user can plug his laptop into whatever network is available (provided it has a connection to the internet), establish a tunnel to a gateway in the home LAN and route everything through the tunnel. This means that the roaming user will always find the same configuration of networking services available once he gets the tunnel to the home LAN up and running. Another typical example is LAN-LAN coupling.

You can find out more about ordinary tunneling (as opposed to encrypted tunnels) in the NET-3-HOWTO. We will instead concentrate on tunnels that encrypt everything that is put into them.


SSH Dynamic Port Forwarding

How to set up an encrypted tunnel using SSH’s dynamic port forwarding (sort of a poor man’s VPN) in Linux . The tools used are OpenSSH and Firefox, but it should be enough info to allow you to figure out how to set up other clients.

Ok... this is quick and easy to do, espacily recommendet if you are in a untrustfull network and you want to have access to privat data.

First start a connection to a Host running sshd, use -D to specify the socks port to use.

$ ssh -D 8080 user@unix.shell.com

No we can use every application which supports "socks", for example firefox.

firefox_settings_sockProxy.png

And now we can surfe save the internet, we are connected truth a encrypted tunnel to a trusted network. This technic works ofcourse also with pop,smtp,irc etc ... As quoted every clients which supports "socks" is usefull here.

This works also under Windows, you need to use putty instead of ssh ( you never heard me saying this !!!)


-- TatWiki - 05 Apr 2006