There is an interesting concept that surfaces sometimes in business, politics or espionage called “Plausible deniability”.  It involves the creation of chains of command that are loose enough to untie when the need arises.  If high ranking officials or politicians become aware of disreputable or questionable activities, they may claim, using “Plausible deniability”, that there is no  way of proving they had any knowledge of such activities.  They can simply deny it, and since there is no direct connection to these high ranking officials, there can be no hard evidence linking themselves to the questionable activity or to the knowledge thereof.  The Plausible deniability concept is also applicable in technology, as you”ll see.

There is this great open-source encryption  software that you can install for free called Truecrypt.  Since most people have bank statements or other sensitive files stored on their computers, this program is for everyone.   You can easily set up what they call an “encrypted volume”.  What is that?  It looks just like any of your letter drives on your computer, but it is really a container of all your encrypted documents.  You can drag your sensitive files right into this new drive and use it just like any other drive, ie: drive F: on your computer.  Truecrypt performs “on the fly” encryption which means that your file is encrypted and decrypted in memory as you use work with it.    When you are done updating a file, it is always written back to the volume encrypted so you never have to worry!

When you mount a Truecrypt volume you need to enter your password and when the computer shuts down down the volume is then unmounted.  If you look at the file that is used to mount these encrypted volumes you’ll see random bits of data.  There is absolutely no way to get any information about your data stored on the encrypted file; it’s just random noise.  To give you an idea of how safe your data is, Truecrypt writes on their website:

“The only way to recover your files is to try to “crack” the password or the key, but it could take thousands or millions of years depending on the length and quality of the password/keyfiles, on software/hardware efficiency, and other factors.”

These guys really covered everything, so it is a highly secure system.  Truecrypt volumes are extremely easy to set up and their website is a great resource for how to get started and learn more about how this technology works.

Back to Pluasible deniability.  Let’s say that I created an encrypted volume and put some very sensitive files in my encrypted container, all is good and my data is quite safe.  Now let’s suppose that some evil  person gains access to your  computer and forces you to give over your secret files he thinks you have.  He knows that you’re smart and that you must have encrypted your sensitive data.  You have no choice but to give him your password and he then can take your files!  To get around this scenario, Truecrypt allows you to create a hidden volume.  A hidden volume is an encrypted volume within another encrypted volume, each having different passwords.  Now, in the case of the evil person, you can say to him “here are my secret files” and give up the password to the outer volume.  The files you “gave” him in the outer volume are not really your sensitive files.  The inner volume contains the truly secret files.  When you open up the outer volume there is absolutely no way of knowing that there is a hidden volume inside.  You have successfully invoked “Plausible deniability” in the sense that your adversary does not know anything other than that outer volume exists and you do not “have” any secret files the adversary wants.  The direct link was severed and you can deny any knowledge of those files.

In a future post we”ll talk about whole disk encryption a new feature of truecrypt. This solution is perfect for laptops or even desktops that contain sensitve data.

Steve Gibson of “GRC.com” has successfully implemented a very cool and extremely robust multi-factor authentication for his GRC employees who need access to an web admin console. He shares his implementation on a series of pod-casts found here. The cool thing about this form of authentication is that he assumes “perfect knowledge”. This means that Steve’s one-time password scheme is extremely secure. So secure, in fact, that if a keystroke logger residing on that machine is recording the keystrokes while a user attempts to log in - that information would not aid an in future attempts to log in. Most sites you visit that contain the typical user log-in, including your online banking site, would be vulnerable to a key stroke logger attack. That is because they require a password that is static. This means the password doesn’t change each time a user logs on. A key stroke logger would be able to identify your password as you type on the keyboard. Armed with this knowledge of your password the attacker can masquerade as you in a future log-on attempt. Another term for this attack vector is called a “replay attack”.In the Steve’s “PPP system” the four-character password, which is a passcode, is different each time the user logs on. There are 16,777,216 possible combinations for each passcode and since no passcode is ever reused, a replay attack would be impossible. The passwords are displayed on a credit card sized piece of paper that can be easily stored in one’s wallet. Steve uses some heavy duty encryption with a highly pseudo random 256 bit key to generate these series of passcodes. Each user will have a 256 bit key that will define the series. This key is stored on the server and the user doesn’t know this key. Another nice feature with this system is that the server will keep track of the passcodes of prior logons, and prompt the user for which passcode that it wants the user to enter. Each column is a letter and each row is a number, therefore the server might show “3E [1]:” so you would type in 5th column 3rd row on the first page. You can also print out your own passcode sheets and if you ever lose a sheet you can tell the server to forward you on to the next sheet, invalidating
the prior passcodes.

The PPP system was well received in the security community and some very practical open-source implementations were created. I downloaded and installed the PPP for PAM module, which allowed me to use PPP when I remote log-on to my MAC using SSH. Interestingly, Steve mentioned that when his employees log on using PPP they also supply a static password in addition to the PPP password. The reason behind this is that if the sheet of passcodes (something you have) got into the wrong hands they would be able to log in as you. However, they still need the static password that only you know, to log on.

I found a really neat Java Class the other day here ; a class that preforms one-way hash encryption. This class has some important Java concepts that beg to be discussed. What does this program do? We touched upon hashing in a previous host when talking public-key encryption. In this example we are taking some text and hashing into gibberish. We call it one-way because it’s impossible (assuming you’re using a good algorithm) to obtain the original text corresponding to this hashed string. One of the applications for this class is password authentication. Let’s say you signed up to use your bank’s online service. When you first started, you created your log-on credentials including a user-name and password. When you log-in, you supply your user-name as well as your password. The bank must have your password stored in a database with your user-name and other identifying information about you. Let’s say this database some how was lost, or some evil employee at your bank decided they wanted to log-on to your account. Assuming they had access, they can query the database and look up your password, right? Actually not if they are using one-way encryption. Instead of storing your password as clear-text it’s hashed into a non-sense value and that value is stored in the database. Now, when anyone looks at this password it’s useless, as they have no way of obtaining your real password. Each time you log in the password you provided is hashed , and compared against the value stored in the database for your password. If they match exactly you are granted access.

This one-way encryption class uses the singleton design pattern. I remember on my interview for my current job being asked to write a Java object using the singleton design. Here is the solution:

public class MySingleton{    

private static MySingleton instance;   

 private MySingleton()    {    }    

public static  synchronized SingletonObject getInstance()    {     

 if (instance == null)       

  instance = new MySingleton();  

return ref;    }

}

Typically Java objects are instantiated like this:
>Object obj = new Object();

A singleton is called differently.

MySingleton signleton = MySingleton.getInstance();

A singleton is an object that cannot be instantiated directly by other developers. The singleton class is controlling how the class itself is created. The first time getInstance() is called, the singleton object is instantiated. Subsequent getInstance() requests will return the instance that was created. The singleton is designed to ensure that there will be only one instance of this class created by the JVM. Why would I do such a thing ? Let’s say you are implementing a program that gives out sequential and unique numbers like the one you take at a crowded deli or Motor Vehicle Office. This class needs to be global across multiple threads, and your takeAnumber() method will be synchronized; meaning only one thread can take a number at a time, thus preventing any concurrency issues. Each “thread” waiting to get “on line” would need to call getInstance() to get the instance of this Counter class, and with the instance they can call the takeAnumber() method. This Counter class can maintain the counter and properly assign unique numbers to each thread. Along a similar vein, that’s why the author of the encryption class used the singleton design pattern. He wanted to be certain that each time the encrypt method was called it would hash into a unique value. By using the singleton design for the class he enforces all threads to use just one copy of the class, and also synchronizes the encrypt method; again making sure there were no collisions to the method by multiple threads. I added my own main method to the PasswordService class. The main method allows users to try out the encryption class by entering in user-names and passwords. I used a HashMap to store users since, I don’t have a database and I want to keep it simple. The key to hashmap is the username, and the encrypted password is the value. Here is my main() method.

public static void main (String args[]){ 

 String input=null;   String [] temp = null;   HashMap users  = new HashMap();  

 PasswordService passwordService = PasswordService.getInstance();

 // getting the instance to the PasswordService singleton class    

do {      

     System.out.println(”(A)ADD,(L)List,AT(Authenticate)”); 

       try {             

                    input = stdin.readLine();              

                        temp=input.split(” “);      

          } catch (IOException e) {              

         // TODO Auto-generated catch block             

                e.printStackTrace();       }   

            try {   

           if(temp[0].equalsIgnoreCase(”A”)){               

            users.put(temp[1],passwordService.encrypt(temp[2]));      

              }    if(temp[0].equalsIgnoreCase(”L”)){       

               for (Iterator iter = users.keySet().iterator(); iter.hasNext();) {          

                       String key=(String) iter.next();            

                      System.out.println(”username=”+key+” (”+users.get(key)+”)”);      

                     }     }   

                   if(temp[0].equalsIgnoreCase(”AT”)){       

              String passedInPassword=passwordService.encrypt(temp[2]);        

             String storedPassword=(String) users.get(temp[1]);    

              if(passedInPassword.equals(storedPassword))        

              System.out.println(”You are succesfully authenticated.”);    

                 else        

            System.out.println(”Wrong password. sorry.”);      

  }    }catch (ArrayIndexOutOfBoundsException e){ 

   } 

 }while(true);}

Here is a screenshot showing the program running. Notice how I added a few users. I then listed all the users currently stored in my hash-map. Along with each user I printed the encrypted password gibberish in parentheses. Notice how there is absolutely no way anyone can get to the password from that mess. Lastly, I authenticated some users.

One of my favorite topics in security is cryptography, the art of hiding information. Today I’d like to talk about public-key cryptography, which is really quite fascinating and ingenious in it’s design. When a message (plain-text) is encrypted it’s turned into gibberish - also called cipher-text. The process of decrypting using a secret key turns the cipher-text back into readable plain-text. So now you have a message you want to send me. We agree on a specific algorithm and a secret key. When you send me a message you use the algorithm with the secret key and encrypt the message. When I receive the nonsense text I use the algorithm with that agreed-upon secret key to decrypt the message and now I can read it. This method of encryption is called symmetric cryptography. We are happy, right ? Not exactly. Let’s say that I”m in Tahiti and you are in New York. There was a breach, and we now need to encrypt all our communications going forward. What do we do? Do we come up with a key and the send it in the mail? Or maybe we can tell each other our secret key over the phone. Can we email it? No, no and no.

Public key cryptography is also called asymmetric cryptography. With asymmetric cryptography we each have a pair of keys; a public key and a private key. The keys are mathematically related, however, the private key can never be derived from the public key. The private key is never distributed; it is always kept secret. The public key is not private and can be distributed freely , even posted in the New York Times if you like. Either the public key or the private key can be used to encrypt a message but the opposite key would have to decrypt the message. So it is never the same key that is used to decrypt as was used to encrypt the message. Let’s say you want to send me a message. You use the agreed upon algorithm with my public key and turn your message into cipher-text. You then send me the message over insecure channels (it doesn’t matter who sees it b/c it’s in encrypted, no worries). I get the message and decrypt using my private key. I can send you a message the same way using your public key.

Now do keep in mind that the scenario I described above ensures confidentiality, meaning nobody but the person with the private key can read the message. What about authenticity? I do not know for sure that you sent me the message since anyone could get my public key and encrypt a message. That’s where digital signatures come into the picture. By signing my message with a digital signature I’m ensuring that it’s me who sent the message. I am also ensuring that no part of the message has been altered in any way. Here’s how it works. I compose my secret message to you but this time I use a hashing algorithm that hashes my message down to a certain numerical value. I then encrypt this hash using my private key and include it with the message encrypting the entire package using your public key. You get this message and decrypt it using your private key. Included in this package is the message and also the digital signature, which you decrypt using my public key. You then take this value with the message and send it through the hashing algorithm. The hashing algorithm will tell you if the hash value is correct. Assuming it is, you now have integrity. You also have confidentiality, nobody could have read the message. The nice thing here is that asymmetric cryptography allows encryption to be done with the private key and decryption to be done public key. Since anyone can decrypt the message using the public key there is no confidentiality in this scenario. However, you know for certain that it was encrypted by the sender’s private key, which insures that it was sent only by that individual. In a future post we’ll talk about SSL (Secure Socket Layer) that uses the methods of encryption discussed in this post.