bill's blog

Just another WordPress weblog

Browsing Posts tagged Public-key

stock_lock
Gnupg public key and corresponding fingerprint:

62E2 067D 9148 9BAA 4A0F 8815 AB5C 668B 5EE0 528C

Public-key cryptography or asymmetric cryptography, is a form of cryptography in which one key is used to encrypt your data and a different key is used to decrypt it. The keys set is broken down into a public key and a private key. The private key is always kept a secret and is never distributed. The Public key as its name implies can be freely distributed. The keys are related mathematically, but one can not derived from the private key from the public one and vice versa. Public-key cryptography addresses two real issues:

1.    Confidentiality
2.    Non-repudiation

In the first case, individuals wanting to transmit confidential data can encrypt the data with the recipient’s public key. Data encrypted with this key can only be decrypted with the corresponding private key. Hopefully, the owner has properly secured their key.  The data in this scenario is actually encrypted! The only problem is that you need to have the public key for every individual you wish to send encrypted data to.

In the second case, individuals wanting to prove that the data in question was actually sent by them would sign the message with their private key. Then anyone who is in possession of the sender’s public key can verify that data was sent by the individual claiming to be the owner. In addition, the recipient can verify that the data has not been tampered with (proving authenticity).  It is interesting to note that the data signed by the individual’s private key is NOT encrypted.  The data being sent is hashed and than the hash is signed with the sender’s private key.

The main problem with this form of cryptography is that one needs to get access to the public key.  Additionally, one must trust that the key is truly from the actual individual claiming ownership. Trust is everything here! In practice there are two ways to deal with this:

1.    Public-Key Infrastructure (PKI)
2.    “Web of Trust”

Both methods rely on the use of a trusted third party.

Public-Key Infrastructure (PKI) relies on the use of a more formalized method of a Certificate Authorities (or CA). These certificate authorities guarantee the ownership of the key pairs. Some of the larger well-known CAs are Thawte, Verisign, Entrust, DigiCert and GoDaddy. These Certificate Authorities provide various levels of security and assurances. It is generally believe that these Certificate Authorities can and should be trusted. Many operating systems vendors (Microsoft, Apple, etc) bundle the CA’s Root Certificates along with their offerings. This makes the process much easier on the end user. It should be noted that any organization can become it’s own Certificate Authority.  In this case, all hosts/individuals looking to trust/use certificates created by the CA must have the its root certificates installed.

The other way to ensure authenticity of keys is through PGP’s “Web of Trust”. In this method anyone can generate a key. Again the problem is a matter of trust.  If you know the individual that the key belongs to is easy to trust the key, BUT what if you never met the individual. Well one way to solve this problem is the ‘six degrees for separation’. Six degrees of separation refers to the idea that, if a person is one step away from each person they know and two steps away from each person who is known by one of the people they know, then everyone is an average of six “steps” away from each person on Earth (wikipedia.org, 2008). This being said, surely we can find someone, who knows someone, who knows the person we’re looking for! The Web of Trust consists of individuals that sign the keys of other individuals that they know and trust. For example:

Bill trusts Joe AND Joe trusts Lucas THEN Bill can trust Lucas.

This may is a bit over exaggerated but the idea is that if I know and trust someone then I can trust the people they know and trust. Extreme care is needed not to turn the ‘Web of Trust’ into a modern day version of Facebook were casual acquaintances are simply accepted at face value. Individuals need to be scrutinized and vetted out.

Resources:

Various, (2008, November 22), Six degrees of separation, Retrieved on December 3, 2008 from http://en.wikipedia.org/wiki/six_degrees_of_separation

SSH Keys

No comments

Let’s say that you have to log into 20 or 30 machines per day. At the end of that day that can lead to a lot of keystrokes. I believe that I’m a focused individual but during the course of that day I can get interrupt may times over. Trying to remember exactly what I am access this host to do can be a challenge at times.

There are those that feel that using ssh keys is an unsafe practice (and it CAN be) if you don’t protect your host correctly. I have this implemented behind a gateway firewall and behind IPFW rules. This being the case a hacker would have to compromise the network and then the host itself. Is this a guarantee that a hacker can’t get to you? No, but it does make it somewhat more difficult to get at the machines.

So the first thing that I need to do is generate the keys that I am going to use.

ssh-keygen -t dsa

You can use other algorithms based on your comfort levels. See the man pages on ssh-keygen to see which flags are built into your version of ssh. You should see something very much like this:

mission-control:~ bheese$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/bheese/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/bheese/.ssh/id_dsa.
Your public key has been saved in /Users/bheese/.ssh/id_dsa.pub.
The key fingerprint is:
52:d4:23:d5:91:b9:2e:0a:41:ac:6a:8d:c9:ee:9c:cc bheese@mission-control.randomdog.net

I did not put a passphase in as I want to be able to access the server using only my ssh keys! ls produces the following out in the .ssh directory.

mission-control:~/.ssh bheese$ ls -al
total 48
drwx------    7 bheese  bheese   238 Mar  2 18:58 .
drwxr-xr-x   30 bheese  bheese  1020 Feb 29 22:51 ..
-rw-------    1 bheese  bheese   672 Mar  2 18:58 id_dsa
-rw-r--r--    1 bheese  bheese   626 Mar  2 18:58 id_dsa.pub
-rw-r--r--    1 bheese  bheese  5828 Dec 27 19:14 known_hosts

To be able to log in to remote systems using your pair of keys, you will first have to add your public key on the remote server to the authorized_keys2 file in the .ssh/ directory in your home directory on the remote machine. Once this is completed… Log into the machine with the account you created the authorized_keys2 for. You will not be prompted for a password.

One of the reasons for doing this is to allow for scripting across the network. Now you can create a script that can be run against a file that contains (or any input from STDOUT) a list of all machines you want the script to deploy on.