Session Keys: a new encrypted connection

Client-side encryption technologies and techniques

Computer Security and Encryption Kasper Munk Rasmussen, April 2011

Abstract This paper suggests ways to make private key encryption communication on the web, and hiding the process from men in the middle. There is need for secure channel establishing without secure socket layer certificates in modern browsing. The paper also discusses the problem of client calculation and server calculation. The paper is not meant as a full solve of these currents problems, but is a step on the road. You will sorrily see that Session Keys is not a system to outplay the SSL technology, due to the fact that Session Keys is not a fully secure technology, but a technology that will raise the bar of non-SSL secured websites.

2 Idea
Now i want to tell of the idea without going into the full details of how Session Keys should be implemented on a website. Session Keys was build with the thought of more secure log in to a website in mind. Sites like Facebook, that has only recently got SSL2. So here we go. A user logs in to a website. Before logging in for real3, the web browser gets a key to encrypt the password. The key is saved on the server together with the ID 4 of the person logging in. When authenticating, the website will get the key to decrypt with by querying with the ID. These six lines is basically the abstract idea of how Session Keys should work. Now, from here many clever computer scientists may be able to solve this task of implementing the system, but in computer science and IT, it's not about how to program, it's about what to program aka. The idea. Now that you are into the idea of Session Keys you may already have had a few thoughts about implementing Session Keys by yourself, but here is my attempt: The first file we have is the file were the user submit his confidential data. This file is linked to a JavaScript that uses AJAX to get the key, with which to encrypt the confidential data. This is the biggest, but maybe the only, security hole in the whole system of Session Keys; for if a a sniffer is sniffing the network5, he may see the file that the JavaScript calls and may see the contents. That is why the whole technology is Session Keys. The session, will make it be a random key, and can only be used by the person with the given session id. I know that of course this doesn't fix the hole, but it 'raises the bar'. A term I am very fond of, that I head at the time studying at Harvard's Introduction to Computer Science I: CS50 course online. The lecturer David Malan used it very often, by holding his hand vertical over his head and saying "... we are just raising the bar." Another thing to point out at this step, is of course the unnecessary use of AJAX, when this could have been implemented from start, and be hidden from less awake sniffers, in some sort of manner6. The AJAX was basically

1 Introduction
My first contribution to the research in the computer science world here in 2011, will be about the system Session Keys. Session Keys is a attempt to create a new way to establish a secure connection between the browser and the website without using the Secure Sockets Layer, and therefore have to buy a SSL certificate. Session Keys is not based on a certain cipher, but is compatible with all ciphers, that can be programmed1. In this thesis I will show you how Session Keys works and I will present the results of my research. The thesis is a result of research under the area of Algorithms for Computer Security and Encryption. With this technology, I am not trying to start a new market, or something like that, and think that this general idea can be further developed, but Session Keys itself, should be inside the boundaries of the academic computer science. Part II, the technical explanation of the technology is in pure text, but a live demonstration has been created for the sake of creating a live showcase of how Session Keys could be used. The demonstration OrangeCrypt Session Keys - Secure Protocol Demonstration is to be found at the website kasmura.com/sessionkeys at the date of the publishing of this thesis, so for anyone interested, that may read this and is sprightly enough to grab the computer, or for anyone reading this on the computer, the website is available, so please visit it. So the problem with today's secure channels in communication across the wire between browsers and websites, is that it is not free! You have to buy a SSL certificate yes, buy. Buy is not a word for the web. The web is free! The web is created from scratch with freedom in mind, and it is very crucial, that the security should not be spoiled by people wanting to charge for what is really only a long long number, when it could as well be free. I am not trying to hold a speech of freedom of the internet, but just want to tell the reason for creating Session Keys.

a way to make everything seem more simple and not so packed. When encrypting, any cipher can be used, as said before. By mean any cipher that can be programmed, I mean, that can be programmed in JavaScript, as JavaScript is the language of the script receiving. Now solution of sending calling a PHP script or an executable file on the server, is available, because it would make the data visible to the sniffer. On the other side of the JavaScript, is the file that gives the key. Another thing the file does is to save the key together with the session ID, and time in a database. Later this will be used to decrypt the ciphertext. The next thing that happens, is that the confidential data is sent through the wire, but encrypted to keep the secure, when going through sniffers and alike. Now, we come to the decryption part of the process, where we before were at the task of encrypting the data without getting others to know about it. The decrypting part is a lot simpler. The first thing to to is just getting to know the Session ID and then look up the Session Key in the database. It might as well check the the current time with the timestamp in the database, just for the case of raising the bar, and adding a little more security, which this system is ind the end all about. Then, by having the key it should use a reverse the cipher to decrypt the data, and then delete the session key from the database. This is the technology of Session Keys.

executed to the user, he does not know what the user is doing with the client application, if the application is not making a call to the server for content, in case of an AJAX application. The criminal person does not know what the user is typing in the password field, before it is submitted, and before that, some JavaScript may already have encrypted the data without calls to the server. But with what key? MD5 does happen to have no key, and the digest of a string will always be the same. When the user clicks the submit button, the password will be encrypted to a MD5 digest, and passed through the wire as cipher text. At the server the same process of encryption will happen. The MD5 received will be compared to the password in the database but as MD5 hash. The basic security hole in this attempt, is that even though the criminal person does not know the password he knows the MD5 digest, and can basically post the MD5 digest together with the username to the server, and would be logged in. Public key is the answer. A public key should be received from the server, just like in the Session Keys example with AJAX or implemented in the HTML document by a server language. The public key will of course be visible to the criminal person, as it is a public key, but when mixed or added to the password and then encrypted to a MD5 digest, the digest will always be different and then the criminal person will not be able to use the same digest twice.

The basic difference between the first and second way of submitting data is of course that the data can easily be compared at the server, without using any password, and therefore breaking the security. When submitting unknown 3 Theoretic data that the server does not already know, this MD5 way is Said simple, one can say that the process at the website or of course not available. server is safe and hidden from the users and therefore the man in the middle. The main problem of non-public key This second attempt of secure submission of data with 8 cryptography is that the calculation at the client is visible to JavaScript will too be included in the Session Keys library . the client himself, but also the sniffer. At the server, all of the process is hidden from the client and therefore for the sniffer, anything happening in the JavaScript part, is References technically vulnerable and open, and therefore the minimum of the process should be executed there. [1] You will later see, that the cipher can not be programmet in any language Session Keys can be used to submit confidential data, but with login the process can be much easier to implement. As [2] And that is only if you go directly to the adress: introduced before in other journals, creating a MD5 digest http://login.facebook.com of the password can be considered safe, if using the right technique. [3] In webprogramming terms before the form being As password submission has much to do with the submitted. current topic, I would like to introduce you to the concept if now familiar. The concept has previously addressed in Ajax [4] Technically the (PHP) session id. in Action7, among other probably. [5] This may happen if the sniffer sniffs the data that is The design of an application in this topic is discussed by going across the wire, and not only the headers. the mean that any person with criminal activities has open access to what application the victim is using and also the [6] By hiding it between nodes or other ways of hiding it. underlying code. The other main sentence, is that although the criminal person knows all about what code is being [7] Ajax in Action, 2006, Dave Crane, Eric Pascarellog with

Darren James. Manning Publications Co. [8] http://kasmura.com