ECE4112 Internetwork Security
Lab ?: Introduction to Cryptography
Group Number:
________
Member Names: __________________________
______________________________
Date Assigned:
Date Due:
Last Edited:
Please read the entire lab and any extra materials carefully before starting. Be sure to start early
enough so that you will have time to complete the lab. Answer ALL questions in the Answer Sheet and
be sure you turn in ALL materials listed in the Turn-in Checklist on or before the Date Due.
Goal: This lab is an in introduction to cryptography, encryption, and related applications. For the
purposes of this lab, we are going to cover applications of cryptography and how to use them effectively
and correctly. We have provided sources for more detailed coverage of cryptography and the
mathematics behind it in Appendix A.
Summary:
This lab will cover the basic principles of cryptography. After a brief discussion of the
basics, we dive into some applications that are built around encryption. First, we cover GnuPG, the
OpenPGP-compatible crypto suite. GnuPG can be used to encrypt and sign just about anything and is
most commonly used as an enhancement for email and personal encryption needs. Then we briefly
cover how to add encryption (SSL) to a network service that doesn't support it. For this we use Stunnel
to encrypt a VNC session. Finally, we break down SSH with an SSHv2 Man-in-the-middle attack and
then give some tips on how to avoid this misfortune.
Background and Theory:
Cryptography is extremely prevalent throughout the electronic world today. No longer is it simply
reserved for governments or other powerful organizations - it is used every day, from email to online
banking to remote logins. It can (theoretically) prevent sensitive information from being observed, if
done correctly. And therein lies the rub - if cryptography is done poorly, it can be very dangerous. A
false sense of security can entice people to give away information that they would otherwise keep
secret, such as credit card numbers or medical records. If you knew that Amazon.com was not secure,
you would not bother giving them your credit card information. However if you only thought they were
secure, you would have no problem giving out sensitive data to potentially the entire world.
There are different needs for encryption and, as they say, more than one way to skin a cat. File
encryption can be different from email encryption and both can be different from SSH or SSL. There
are, however, also similarities between them in the types of algorithms that are used and sometimes
even in the methods in which they are use.
Now let’s cover some of the basic types of encryption and the algorithms used. As a convention, we will
use the names Alice and Bob to indicate users sending data between A and B. Eve will be a possible
eavesdropper.
Symmetric Key Cryptography
Symmetric encryption algorithms are methods of encryption were both decryption and encryption use
the same shared key. Almost all encryption makes use of this at some point, due to the speed
advantages these algorithms have over public key schemes. When someone refers to 128 bit
encryption, they are referring to the number of bits in the key - the more bits, the longer it will take to
crack. Most commonly used encryption algorithms are roughly equal in strength for the same key
length.
1
Alice will encrypt her message, M, with the key, K, and send the ciphertext to Bob.
Bob then uses K and applies the decryption algorithm to generate M.
Eve is unable to generate M without knowing K.
Some symmetric algorithms that are currently in use are:
Twofish - A 128-256 bit algorithm that was a candidate for the AES standard.
TDES - Triple DES encryption. Performed by successively DES encrypting data 3 times with 3 different
keys. Being phased out for AES.
AES - Current US Government standard for encryption. Supports 128-256 bit keys
RC4 - Used in WEP, however due to a poor implementation, was easy to crack. The Algorithm also
suffers from a comparatively weak key schedule.
Diffie-Hellman Key Exchange
It is worth mentioning the most common method for agreeing on the symmetric key, the Diffie-Hellman
(DH) exchange. This allows two parties to generate a shared key without actually transmitting the key
itself. Warning - Some math ahead.
1. Alice and Bob agree on a prime p and a specific number g < p-1.
2. Alice makes a random number a and sends Bob the result of (g^a) mod p
3. Bob does the same as Alice, sending (g^b) mod p
4. Now Alice can use Bob's message - (g^b) mod p - and a and p to compute (((g^b) mod p)^a) mod
p
5. Bob does the same and comes up with (((g^a) mod p)^b) mod p
Due to the fact that g^a^b = g^b^a, each side has the same secret number and it is very difficult for
anyone in the middle to determine, due to the difficulty of taking discrete logarithms. If Eve listens to
the conversation, all she can get are p, g, (g^a) mod p and (g^b) mod p. It may seem like Eve could
calculate either a or b, however in practice this is very computationally hard for the large numbers that
are used.
There are problems with this method, due to the lack of authentication of Alice's result she sends to
Bob and vice versa. It is possible to launch a man in the middle attack, which is shown later in the lab.
Public Key Cryptography
All public key (PK) cryptography is based on sets of functions that allow for one way encryption or
decryption. Simply put, you have one key used to encrypt data, and another key used to decrypt the
data. The entire need for this is due to the problems of establishing a shared key to use for a symmetric
algorithm. With PK cryptography, both parties can have each others public key that is used to encipher
data. When they receive encrypted data, they can then use their private key to decrypt. These keys can
also be used to digitally sign messages, allowing the receiver to use the public key to verify the identity
of the message. It should be noted that PK systems require much longer key lengths to be as secure as
symmetric algorithms, around 1024 bits or higher.
Public Key Algorithms:
DSA - Digital Signature Algorithm. Currently the US Government standard for digital signatures. Cannot
only be used for message signing.
RSA - One of the very first PK algorithms. This supports both signing and encryption. Probably the most
widely used PK algorithm.
Alice generates both a private key and a public key.
Alice sends her public key to Bob.
Now Bob can encrypt a message with Alice's public key.
Alice decrypts Bob's message using her private key.
Now neither side needs to have a shared secret to communicate. The downside is that these operations
are relatively time consuming, especially when compared with the symmetric algorithms. The other
issue is that if a private key has been compromised, all data that was encrypted with the corrosponding
public key is also compromised. This is not an issue with a DH key exchange because a new key can be
generated frequently (every conversation for example). It can also be difficult/time consuming to
2
redistribute the new public key and invlaidate the old one.
Other resources that may prove useful during this lab:
http://en.wikipedia.org/wiki/Cryptography
http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange
http://www.rsasecurity.com/rsalabs/node.asp?id=2152
Prelab Questions:
PQ 1. Assuming Alice and Bob agree on prime p=11 and g=2. Alice's a=5 and Bob's b=4.
What is the shared secret that is determined from a DH key exchange?
Lab Scenario:
Section 1: Gnu Privacy Guard
Gnu Privacy Guard (GnuPG) is a publicly available cryptography suite that conforms to the OpenPGP
standard. GnuPG has the ability to encrypt messages, and also digitally sign them. It can be used on
the command line, or with one of multiple available graphical frontends. It also works with many
popular email clients, though some require a plugin to be installed first. We will be invoking GnuPG
from the command line in order for you to better understand what we are doing and how to use the
tool.
1.1 Key Creation and Distribution
GnuPG is already available on our Red Hat WS 4.0 machine so we don't have to install anything new.
Since this is our first time using GnuPG, we need to run it once so it generates config files:
$ mkdir ~/.gnupg
$ gpg
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: Go ahead and type your message ...
Hit Ctrl-D to quit here, we don't have anything to input at this time. DO NOT hit CTRL-C, you will have
to start over.
Run it a second time so it generates the public and private keyring:
$ gpg
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: Go ahead and type your message ...
Hit CTRL-D again.
Your private keyring is for holding your own personal private key(s). The public keyring is for holding
your public key and all of the public keys you have collected from contacts and friends.
Now generate a keypair:
$ gpg --gen-key
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) ElGamal (sign and encrypt)
Your selection?
The default is fine, press ENTER. DSA stands for Digital Signature Algorithm and is used for signing
messages. ELGamal is usable for encryption as well as signatures.
DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
3
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024)
Default is good, hit ENTER.
Requested keysize is 1024 bits
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)
Hit ENTER, you key will be forever valid.
Key does not expire at all
Is this correct (y/N)?
Type 'y' and then ENTER. Now, you must enter your personal information.
You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
“Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>”
Real name: <enter first and last name>
Email address: <enter email>
Comment: <any comment such as a nick-name>
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit
When you are satisfied, type 'O' and hit ENTER.
Next you will be prompted to enter a passphrase to protect your private key. If someone else gets a
hold of your private key, this passphrase is your only defense. For the purposes of this lab, just pick
something that is easy to remember. When GnuPG prompts you, start (gently) mashing randomly on
the keyboard, erratically move the mouse around, and open some programs in order to seed the
entropy pool. The longer your key length, the more secure it is, but also the faster it will empty the
entropy pool. The more entropy, the better your random numbers will be ("better" meaning harder to
guess).
Enter passphrase:
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.
+++++.+++++.+++++++++++++++++++++++++.+++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++>++++++++++..............................
.......................................................................................
.................................<+++++......>+++++.<+++++>.+++++.......>+++++..<+++++.
.....>.+++++.............................................................+++++
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.
+++++++++++++++.+++++..++++++++++..++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++....+++++++++++++++++++++++++.+++++>+++++..+++++^^^
gpg: /root/.gnupg/trustdb.gpg: trustdb created
public and secret key created and signed.
4
key marked as ultimately trusted.
pub 1024D/FC85F242 2006-12-05 ECE4112 (Call me Bob) <ece4112@fakeemail.com>
Key fingerprint = C570 52C2 684E 7346 A833 E2F6 1CC6 2A60 FC85 F242
sub 1024g/57293FAF 2006-12-05
Okay, now you have your public and private keys. Let's take a look:
Screenshot #1 - Output of 'gpg --list-keys'
$ gpg --list-keys
/root/.gnupg/pubring.gpg
-----------------------------------pub 1024D/FC85F242 2006-12-05 ECE4112 (Call me Bob) <ece4112@fakeemail.com>
sub 1024g/57293FAF 2006-12-05
Make sure you know what the values mean in the output. In this example,
Key Length = 1024D
User ID = FC85F242
You will be required to use your User ID in the future.
You can also check out the fingerprint of a given User ID like so:
$ gpg --fingerprint <User ID>
/root/.gnupg/pubring.gpg
-----------------------------------pub 1024D/FC85F242 2006-12-05 ECE4112 (Call me Bob) <ece4112@fakeemail.com>
Key fingerprint = C570 52C2 684E 7346 A833 E2F6 1CC6 2A60 FC85 F242
sub 1024g/57293FAF 2006-12-05
Note: To share your key with friends, the most common method is to use a public key server. To let
GnuPG talk to your public key server you need to set the 'keyserver' option in ~/.gnupg/options to
point to a valid server. Once you have that configure, GnuPG can send your public key to the server
with 'gpg --send-key <User ID>'.
Since we are not using a keyserver, copy the ECE4112 public key out of the NAS folder for this lab and
into your current directory. It is called 'ECE4112_pub.asc'. Import it into your public keyring. We use
the '--armor' flag because the file is in ASCII-armor format (plaintext). ASCII-armor is a bit more
friendly to pass around and use in email than binary is.
$ gpg --armor --import ECE4112_pub.asc
gpg: key FC85F242: public key "ECE4112 (Call me Bob) <ece4112@fakeemail.com>" imported
gpg: Total number processed: 1
gpg:
imported: 1
Now you have someone else's public key. You can send them messages and verify their digital
signatures.
1.2 Signing and Encryption
When you digitally sign a file, the file contents are not changed or encrypted. The purpose of a digital
signature is to verify that a message has not been tampered with or forged. If you receive a digitally
signed email, the digital signature will either be an attachment or just included inline at the bottom of
the file after the message body. If your email client is set up to work with GnuPG it should
automatically recognize this, otherwise it will just ignore it (you can still manually verify the signature,
though). A digital signature can be thought of as the digital equivalent of a seal.
Q 1.2.1 Why is it important that a digitally signed message has either a date or a unique
message ID?
5
Now create a short text file named groupXX.txt with one or two sentences. Sign the text file like so
(you will be prompted for your passphrase):
$ gpg --clearsign < groupXX.txt > signed.txt
Screenshot #2 - Printout 'signed.txt' and turn it in with your lab.
Q 1.2.2 What type of key was used (DSA or ELGamal) and what size?
Copy the ECE4112_signed.asc from this lab's folder on NAS your local machine. Verify the signature:
$ gpg --verify < ECE4112_signed.txt
Screenshot #3 - Take a screenshot of the verified message (ignore the Warning).
Note: There will be a warning because the public key used to sign this message has not been signed by
anyone else. In the real world, you can ask people who personally know you to sign your public key
with their key in order to build trust and get rid of that warning. This builds a "network of trust" or a
"web of trust". See the references at the end of this section for more on this topic.
Now, suppose you have a document you want to encrypt -- but you do not need to sign it since it is for
your own personal use.
Screenshot #4 - Take a screenshot of a terminal with both the encrypted and unencrypted
text using the commands below:
$ gpg --armor -r <Your User ID> --encrypt groupXX.txt
$ cat groupXX.txt.asc
-----BEGIN PGP MESSAGE----Version: GnuPG v1.2.6 (GNU/Linux)
< BLOCK OF SCRAMBLED CHARACTERS >
-----END PGP MESSAGE----$ gpg --armor --decrypt group00.txt.asc
You need a passphrase to unlock the secret key for
user: "ECE4112 <ece4112@fakeemail.com>"
2048-bit ELG-E key, ID EE5DF1BD, created 2006-12-05 (main key ID BA7F276F)
gpg: encrypted with 2048-bit ELG-E key, ID EE5DF1BD, created 2006-12-05
"ECE4112 <ece4112@fakeemail.com>"
This is an example message for ECE4112 crypto lab. The quick brown fox jumps
over the lazy dog.
The two sentences at the end are what was in the file before I encrypted it, you can have different stuff
in your file.
If you want to send a file to someone else, you should encrypt and sign the file so that they can verify
that the file is from you, and so nobody else can intercept and read the contents of the file.
To Sign and Encrypt (You don't actually need to run this for the lab)
$ gpg --armor -r <Recipient User ID> --sign --encrypt < message.txt > signed_secret.txt
Q 1.2.3 Assuming you were the recipient in the above command, how would you decrypt the
message and verify the signature?
6
GnuPG Sources:
http://demenzia.net/articles/gpg-introduction/
http://www.scramdisk.clara.net/pgpfaq.html
http://www.kuro5hin.org/story/2000/5/1/17058/47630
http://www.kuro5hin.org/story/2000/5/9/193916/2290
Section 2: Encapsulating services with SSL
One of the simplest ways to add some security to your server is to make sure that all your services are
encrypted. This is not always easy, however, as some services and client software do not come out of
the box with SSL support. There is a cheap and easy solution with Stunnel (stunnel.org). Stunnel allows
you to encapsulate any client or server with SSL.
2.1 Stunnel and VNC
VNC is a remote desktop viewer. It allows you to use your desktop over a network as if you were sitting
at the local machine. The free version of VNC (realvnc.com) uses a simple challenge-response protocol
to verify passwords but does not encrypt the rest of the session. You can purchase the professional
version which supports encryption -- or, if you are a poor student, you can wrap VNC with Stunnel.
First we need to install VNC on both the Red Hat WS 4.0 machine, and the WinXP virtual machine
image. If you have done this in a previous lab, you can skip this part -- the installation portion is just
copied from that lab.
We are going to setup the VNC server on the WinXP machine, and connect to it with the client on the
Red Hat WS 4.0 machine.
Before we start, let's take down the Red Hat firewall just to make sure we have all the ports open we
need. (This is not a smart thing to do on a normal networked system):
# /etc/init.d/iptables stop
Installing VNC on Windows
Copy the file vnc_x86_win32 folder from the NAS server’s tools/Windows folder to the tools folder on
your hard drive.
1. Change into the vnc_x86_win32/winvnc directory and double click the Setup program
2. Click OK on warning about installation of previous version.
3. Click Next
4. Click Yes on License Screen
5. Click Next for destination location default
6. Click Next for Program, Folder default
7. Click Finish
Installing and Running VNC on the Linux Machine
Switch to the /home/tools directory, where you extracted all the linux tools, and run the following
command:
#tar xvfz vnc-3.3.3r2_x86_linux_2.0.tgz
7
Go into the VNC directory that is created. You will see that there are five different executable programs.
Go ahead and read the README file as this will provide you with explanations about what each of the
executables do.
To run the VNC server, you need to copy the VNC executables into /usr/local/bin:
# cp vnc* /usr/local/bin
# cp Xvnc /usr/local/bin
Now run the server to make sure everything is in working order:
# vncserver
Enter a password for the connection and remember it because you will need to enter it in the client. On
the WinXP machine you can start the client from the Start Menu. Enter your Red Hat WS 4.0 ip address
and the password you chose. After you verified VNC is working, shut it down and continue to the
Stunnel setup.
Installing Stunnel on Red Hat WS 4.0
It's already installed, you don't have to do anything here.
Installing Stunnel on WinXP
Copy stunnel-4.20-installer.exe from NAS onto your WinXP machine and run the installer. All the default
options are fine.
On Windows, due to our use of Stunnel VNC thinks you are trying to connect to a local machine and will
refuse to connect. A quick registry fix will take care of that issue. Open notepad, paste the below text
into it and save it as VNCReg.reg.
--cut here-REGEDIT4
[HKEY_LOCAL_MACHINE\Software\ORL\WinVNC3]
AllowLoopback=dword:00000001
[HKEY_LOCAL_MACHINE\Software\ORL\WinVNC3\Default]
AllowLoopback=dword:00000001
--stop here-Double click the file to run it and import the settings into the registry.
On the RH machine, open up ethereal and start sniffing traffic in promiscuous mode, with transport
name resolution turned on.
On the RH machine, execute the following and let it run in it's own terminal:
# stunnel -d 5900 -r 5901
# ./vncserver
(make sure you are in the right directory)
On the WinXP machine open a command prompt and run this:
> stunnel -d 5900 -r <RedHat IP>:5900 -c
Now, on the WinXP machine, connect to localhost (127.0.0.1) without specifying a display. By
connecting to VNC display 0 on the localhost, Stunnel will transfer all the traffic to the Red Hat machine
on display 1. So the VNC server on the Red Hat machine must be running on display 1. Not display 0. If
you run Stunnel before VNC, VNC will automatically move to display 1 noticing that port 5900 ("display"
0) is already in use).
What we now have is an "unsecure" connection from the WinXP VNC client to the Stunnel port on
WinXP. This tunnels the traffic over a "secure" SSL connection to the Stunnel instance running on the
RH machine. The "unsecure" decrypted traffic coming from Stunnel on the RH machine is sent to the
8
VNC server on the same machine.
Screenshot #5 - Take a screenshot of the SSL traffic in Ethereal
Stunnel Sources:
http://www.math.ias.edu/doc/stunnel-4.05/VNC_StunnelHOWTO.html
Section 3: SSH
SSH is a very common service - it has almost completly replaced telnet for logins to remote systems.
However, the security of SSH depends on how well the server is set up. A badly configured server could
be worse than none at all, since a false sense of security is much more dangerous (people are less
likely to think that something is wrong and more likely to trust it with sensitive information). The
primary danger is in the setup of the authentication methods. Ideally, authentication should be
provided in two parts - something you know, and something you have. Generally, many people only
uses the first of these - "something you know" - in the password you have for your account. The
problem with this method is that passwords can be intercepted and host keys can be forged, allowing
for Man-in-the-middle (mitm) attacks to occur. It is possible, however, to distribute keys ahead of time,
thus giving the user a key to use in conjunction with their password. This would satisfy the requirement
of both knowing and having something to complete the authentication.
All SSHv2 connections negotiate an encrypted tunnel between the client and server by performing a
Diffie-Hellman (DH) key exchange to agree on a symmetric encryption key. The key exchange is also
signed using whatever the prefered algorithm of the client that the server accepts. The details of a DH
key exchange are in the appendix. After the encrypted tunnel is created, the client must then
authenticate itself to the server.
The authentication methods that SSHv2 supports are as follows:
publickey - The server and client have predistributed their public keys and use this to sign messages
password - The client sends a password through an encryption tunnel
hostbased - Public keys are tied to a specific host name, allowing logons from a specific host
The only method that must be accepted by all SSH servers is the publickey method. Despite this being
the case, most servers also accept passwords which can make them vulnerable to mitm attacks. Now,
when the server does the DH key exchange before the authentication, it still digitally signs the
exchange - this, in theory, allows the client to compare the key against a known list and determine if it
is valid or if it has changed. The problem comes with the fact that the client may have never seen the
server before (in the case of a public computer in a library or coffee shop). In this case, the server's
public key is sent along with the key exchange itself - allowing for a mitm attack. All of this occurs
before the actual authentication has taken place - the client still has a chance to bail out of the
connection if it determines that it is not communicating with the real server.
This is where the previously mentioned authentication methods are used. These allow the client and
server to verify each others identities. The best method is the pubickey, simply due to the fact that it
requires prior information that an attacker would not have.
First, lets take a look at what type of encryption our server allows. You should already be running an
SSH server on your RH4 WS machine, so simply telnet to the localhost on it and type "SSH-2.0client"and take a screenshot or copy of the output from the server.
Example (yours may look different):
$ telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3p2 Debian-5.1
9
SSH-2.0-client
¼ •Pº?ªxZ ¶•ldiffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffiehellman-group1-sha1ssh-rsa,ssh-dss
...
Screenshot #6 - Telnet into ssh
(the '...' just indicates other text that was clipped for brevity.)
Exit this connection. Now start Ethereal up and begin sniffing traffic. On your RedHat 7.2 VMWare
image, connect to the the RH4 WS machine. After you connect, you can immediately disconnect - we
are only interested in the key exchange. Now go back to the RH4 WS machine and stop ethereal. Look
through the packets to find the SSH key exchange initialization.
Q 3.1. What are the preferred server_host_key_algorithms by the server? by the client?
Q 3.2. What is the server host key algorthim that will be used (hint - they are in order of
preference)?
Q 3.3. How could a mitm attacker make the client accept a different host key without
indicating it had changed?
Now we will use a tool known as SSHarp to sniff the password used in the SSH connection. First we
must get ssharp from http://stealth.openwall.net/SSH/7350ssharp-0.52.tgz
Once we have this, extract it, configure, make and install as root.
# tar -xzvf 7350ssharp-0.52.tgz
# cd ssharp
# ./configure ; make ssh; make
# make install
# cp ssh /usr/local/bin/ssharpclient (or whatever your path is)
Now setup forwarding and start the ssharp server by typing
# iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 10000 -i eth0
# ./sshd -d -4 -p 10000 -7
You must hit enter after you run the command. You should see the debug messages being output when
the server is running correctly. In the real world, the attacker would also use DNS cache poisoning or
arp cache poisoning to redirect traffic.
Now, on the RedHat 7.2 VMWare machine, attempt to connect to the RH4 WS machine. The passwords
are stored in /root/ssharp.
Q 3.4. Do you see the attempted password logged on the RH4 WS machine?
Q 3.5. Which message did you get? A warning your the host key has changed or that it is
simply new? Why?
This is obviously very dangerous. Many, many people allow logins with passwords - even Georgia Tech's
own acme & and the ECE department's yamsrv systems allow this! Just because something claims to
use "good" encryption does not make it perfect - this demonstrates that encryption is an entire model
that is only as strong as its weakest link. In this case, that link is the clients trust that the server it is
talking to is actually the real server - it has no way of knowing, unless you expect users to memorize
the server's host key that is presented. A much better way is to do what was mentioned earlier - force
the users to use a preshared key. By using the private key to sign the message and the public key to
verify, you can prevent the observed mitm attack. It is important to note that the private key can be
kept on a usb stick or on a smart card and with the user at all times. The key is also encrypted with a
password that only the user knows. Thus we now have a security system that requires something the
user has (the private key) and something the user knows (the passphrase).
On the RH 7.2 VMWare machine, create a public/private key pair and transfer it to the server.
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa):
10
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ~/.ssh/id_rsa.
Your public key has been saved in ~/.ssh/id_rsa.pub.
The key fingerprint is:
be:06:3f:cc:84:63:b0:0a:59:37:9d:ec:98:d3:c2:53 mattd@localhost
Include a screenshot of your key generation.
Screenshot #7 - Key Generation
Now transfer the public key, id_rsa.pub, to the RH4 machine. For the lab, we will use SSH. Even if the
public key was sniffed, the attacker cannot do anything but verify that you actually have the
$ scp ~/.ssh/id_rsa.pub root@<RedHat 4 ip here>:
Now switch to the RH 4 WS machine and open a root window. We must tell ssh that this key is valid to
be used to logon with.
# cd ~/.ssh
# cat ../id_rsa.pub >> authorized_keys
Now, we must tell the server to disallow password logins. Do this by edititing the /etc/ssh/sshd_config
file. Find the line that says "PasswordAuthentication yes" and change it to "no". If this line does not
exist, add it. Now restart the sshd server. Also flush the iptables rules.
# /etc/init.d/sshd restart
# iptables -t nat -F
On the client side create a file in your home directory called ~/.ssh/config . In it place the line
"PasswordAuthentication no" to prevent your client from prompting you for a login password. You will
still need your private key passphrase, but this is only used for decrypting the private key and is never
transmitted across the network.
Now, from the RH 7.2 VMWare machine, try to login to the RH4 Workstation machine. You should be
prompted for the passphrase that you entered in earlier - this is only to decrypt the private key and is
not sent over the network. Include a screenshot of the ssh client prompting you for the passphrase.
[root@redhat7 root]# ssh <RH4 WS>
Enter passphrase for key '/root/.ssh/id_rsa':
Last login: Mon Dec
Screenshot #8 - SSH client prompting for passphrase
Now we will show what happens if someone attempts to use ssharp after you have setup public keys.
On the RH4 WS machine, re-enable the ipforwarding and start ssharp.
# iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 10000 -i eth0
# ./sshd -d -4 -p 10000 -7
Switch to the RH 7.2 VMWare machine and attemp to connect to the ssh server.
Q 3.6. Write down the error message you see.
Now the connection is safe from mitm attacks like the one described. The only downside to this method
is that it does require the user to keep track of a private key. If they keep the key on a smartcard or
their usb drive and it is left at home, they would be unable to logon to the system.
SSH Sources:
http://www.phrack.org/archives/59/p59-0x14
http://www.shellcode.com.ar/docz/asm/ssharp.pdf
http://tools.ietf.org/html/rfc4251
http://tools.ietf.org/html/rfc4252
http://tools.ietf.org/html/rfc4253
11
Appendix A: Further Reading
Cryptography and Encryption
A Beginner's Guide to Encryption by Jonathan Read and Seth Fogie:
http://www.informit.com/guides/content.asp?g=security&seqNum=133&rl=1
Applied Cryptography by Bruce Schneier
Practical Cryptography by Niels Ferguson and Bruce Schneier
SSH
OpenSSH Key Management by Daniel Robbins:
http://www-128.ibm.com/developerworks/library/l-keyc.html
SSH Host Key Protection by Brian Hatch:
http://www.securityfocus.com/infocus/1806
SSL
How does SSL Work?:
http://www.ourshop.com/resources/ssl.html
SSL Certificates Howto by Franck Martin:
http://www.gtlib.cc.gatech.edu/pub/linux/docs/HOWTO/other-formats/html_single/SSL-CertificatesHOWTO.html
Appendix B: Suggested Add-ons and Future Enhancements







OTR encryption with plausible deniability
How SSL and Certificate Authorities work (look at OpenSSH's CA.pl)
Rainbow Tables, and salting your hashes
Drive volume encryption (TrueCrypt, etc.)
Code Signing
S/MIME
ZFone
12
TA Setup Instructions
On NAS, create a folder corresponding to this lab number. In it place all the contents of the
'LabMaterials' folder on the CD. I included the private/public keyring as well as the password for the
gnupg 'friend' in the lab on the CD if you wanted to extend or modify that portion of the lab. They are in
the ECE4112_gnupg folder.
Answer Sheet Lab ?
Introduction to Cryptography
Group Number:
________
Member Names: __________________________
______________________________
Prelab Questions:
PQ 1. Assuming Alice and Bob agree on prime p=11 and g=2. Alice's a=5 and Bob's b=4.
What is the shared secret that is determined from a DH key exchange?
Section 1: Gnu Privacy Guard (GnuPG)
Q 1.2.1 Why is it important that a digitally signed message has either a date or a unique
message ID?
Q 1.2.2 What type of key was used (DSA or ELGamal) and what size?
Q 1.2.3 Assuming you were the recipient in the above command, how would you decrypt the
message and verify the signature?
Section 2: SSH
Q 3.1. What are the prefered server_host_key_algorithms by the server? by the client?
Q 3.2. What is the server host key algorthim that will be used (hint - they are in order of
preference)?
13
Q 3.3. How could a mitm attacker make the client accept a different host key without
indicating it had changed?
Q 3.4. Do you see the attempted password logged on the RH4 WS machine?
Q 3.5. Which message did you get? A warning your the host key has changed or that it is
simply new? Why?
Q 3.6. Write down the error message you see.
How long did it take you to complete this lab? Was it an appropriate length lab?
What corrections and/or improvements do you suggest for this lab? Please be very specific and if you
add new material give the exact wording and instructions you would give to future students in the new
lab handout. You may cross out and edit the text of the lab on previous pages to make minor
corrections/suggestions. General suggestions like add tool xyz to do more capable scanning will not be
awarded extras points even if the statement is totally true. Specific text that could be cut and pasted
into this lab, completed exercises, and completed solutions may be awarded additional credit. Thus if
tool xyz adds a capability or additional or better learning experience for future students here is what
you need to do. You should add that tool to the lab by writing new detailed lab instructions on where to
get the tool, how to install it, how to run it, what exactly to do with it in our lab, example outputs, etc.
You must prove with what you turn in that you actually did the lab improvement yourself. Screen shots
and output hardcopy are a good way to demonstrate that you actually completed your suggested
enhancements. The lab addition section must start with the form “laboratory Additions Cover Sheet”
which may be found on the class web site.
14
Attach to your submission:
8 screenshots
ECE4112 Lab ?: Introduction to Cryptography
Answers
Prelab Questions:
PQ 1. Assuming Alice and Bob agree on prime p=11 and g=2. Alice's a=5 and Bob's b=4.
What is the shared secret that is determined from a DH key exchange?
A) 1. 1
Section 1: Gnu Privacy Guard (GnuPG)
Q 1.2.1 Why is it important that a digitally signed message has either a date or a unique
message ID?
A) It helps prevent people from re-sending signed messages in the future or after circumstances have
changed and the messages might still appear to be valid. GnuPG adds the date for you so you don't
actually have to manually enter it.
Q 1.2.2 What type of key was used (DSA or ELGamal) and what size?
A) DSA, 1024
Q 1.2.3 Assuming you were the recipient in the above command, how would you decrypt the
message and verify the signature?
A) $ gpg FILENAME (gpg knows what to do by default so no options are needed)
Section 2: SSH
Q 3.1. What are the prefered server_host_key_algorithms by the server? by the client?
A) Depends on the server configuration - should be either ssh-rsa or ssh-dsa.
Q 3.2. What is the server host key algorthim that will be used (hint - they are in order of
preference)?
A) Whatever they listed for the client should be here. Probably ssh-rsa.
Q 3.3. How could a mitm attacker make the client accept a different host key without
indicating it had changed?
A) Pretend to only offer the key that is not prefered, forcing the client to accept it - More than likely it
has never been seen before.
Q 3.4. Do you see the attempted password logged on the RH4 WS machine?
A) Yes - they should be in the /root/ssharp file
Q 3.5. Which message did you get? A warning your the host key has changed or that it is
simply new? Why?
A) The message should tell you you have never seen this key and ask you to accept. This is because
ssharp sends the key that is not prefered, thus the prefered key has not changed.
Q 3.6. Write down the error message you see.
A) Should be similar to:
Permission denied (publickey)
This is due to the ssharp trying to force you to use a password when your client is setup to dissallow
15
passwords.
16
Screenshots
Section 1: GnuPG
Screenshot #1 - Output of 'gpg --list-keys'
Similar to:
$ gpg --list-keys
/root/.gnupg/pubring.gpg
-----------------------------------pub 1024D/FC85F242 2006-12-05 ECE4112 (Call me Bob) <ece4112@fakeemail.com>
sub 1024g/57293FAF 2006-12-05
Screenshot #2 - Printout 'signed.txt' and turn it in with your lab.
This basic format:
-----BEGIN PGP SIGNED MESSAGE----Hash: SHA1
<SOME TEXT>
-----BEGIN PGP SIGNATURE----Version: GnuPG v1.2.6 (GNU/Linux)
<SOME SCRAMBLED CHARACTERS>
-----END PGP SIGNATURE----Screenshot #3 - Take a screenshot of the verified message (ignore the Warning).
This, exactly:
gpg: Signature made Tue 05 Dec 2006 06:19:35 AM EST using DSA key ID FC85F242
gpg: Good signature from "ECE4112 (Call me Bob) <ece4112@fakeemail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:
There is no indication that the signature belongs to the owner.
Primary key fingerprint: C570 52C2 684E 7346 A833 E2F6 1CC6 2A60 FC85 F242
Screenshot #4 - Take a screenshot of a terminal with both the encrypted and unencrypted
text
This basic format:
$ gpg --armor -r <Your User ID> --encrypt groupXX.txt
$ cat groupXX.txt.asc
-----BEGIN PGP MESSAGE----Version: GnuPG v1.2.6 (GNU/Linux)
<BLOCK OF SCRAMBLED CHARACTERS>
-----END PGP MESSAGE----$ gpg --armor --decrypt group00.txt.asc
You need a passphrase to unlock the secret key for
user: "ECE4112 <ece4112@fakeemail.com>"
2048-bit ELG-E key, ID EE5DF1BD, created 2006-12-05 (main key ID BA7F276F)
gpg: encrypted with 2048-bit ELG-E key, ID EE5DF1BD, created 2006-12-05
"ECE4112 <ece4112@fakeemail.com>"
<A COUPLE SENTENCES>
Section 2: Encapsulating services with SSL
Screenshot #5 - Take a screenshot of the SSL traffic in Ethereal
Ethereal with SSL traffic.
17
Section 3: SSH
Screenshot #6 - Telnet into SSh
$ telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3p2 Debian-5.1
SSH-2.0-client
¼ •Pº?ªxZ ¶•ldiffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffiehellman-group1-sha1ssh-rsa,ssh-dss
...
Screenshot #7 - Key Generation
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ~/.ssh/id_rsa.
Your public key has been saved in ~/.ssh/id_rsa.pub.
The key fingerprint is:
be:06:3f:cc:84:63:b0:0a:59:37:9d:ec:98:d3:c2:53 mattd@localhost
Screenshot #8 - SSH client prompting for passphrase
[root@redhat7 root]# ssh <RH4 WS>
Enter passphrase for key '/root/.ssh/id_rsa':
Last login: Mon Dec
#
ECE4112 New Lab
Group 18
Introduction Cryptography
Matt DeVoe and Matt Manzel
2006-12-05
18