 Hello. Sorry. Okay, so hi everyone and welcome to track one. Our talk here at 430 is how to secure the keyboard chain and our speakers today are Paul, Amaceli and Baptiste David. And here they are. Please help me welcome Paul. So, hi everyone. Thank you for coming. Here's Baptiste David and I'm Paul Amicelli. We are from France and we are working on a computer security lab. So today we're going to talk about how to secure the keyboard chain against a certain type of viruses which are kilo girls. So it's all done under windows. So sorry for the notions. As we don't have so much time, we will quickly see the kilo girls forms and then the main of our works with some details and we will hand up with some ideas we had to go further. So, what's a kilo girl? Basically kilo girls are a little piece of software or hardware or whatever you want which is able to retrieve every piece of information that can be tipped on a keyboard, meaning for instance a credit card number, bank account credentials, reports of companies and so on. They are underestimated since they can nestle everywhere and they are barely invisible. And as we are going to see in a few moments, they are quite easy to develop. So first we have to see how the keyboard chain works. They are three major stages. The hardware part. So basically each key is a switch and when you press a key, it generates an interrupt with a code called the scan code. And this is handled by the kernel part of the operating system which consists of a set of driver. So we have the I8042 port which is the driver port which basically handles every event on the keyboard and on the mouse. And then we have the keyboard class which allows to extend the functionalities by the keyboard manufacturers. Then this code is handled by the ring-free part of the operating system, a sub-module of Windows which converts the keyboard code into a Windows message which will be understood by all the application and the operating system itself. Well, when you want to make a kilo girl, you've got many ways to do it. First you can create a user mode one which is quite easy to develop because it's quite easy to find codes and examples on the Internet. And in addition, it's really easy to install. It normally doesn't require any specific rights and it's a very good piece of software which is enough to do the job or request it. But most of these kilo girls are very well known malware so it can be detected by most of the software on the market. And because they are detectives, they are removable from the system and it's very efficient but not so strong. If you want something stronger, you can use kernel mode one. So in fact it's just driver which are inserted inside the keyboard driver stack and it's much more efficient because they've got a prior access to the keystroke press. When the user selects the keystrokes, the first notified are the driver from the kernel of Windows. So this is why they are first notified. But it's a bit harder to develop because you need to develop a driver and you need to have specific rights like admin rights to install the driver on the system and on X64 Windows subsystems, you need to sign the driver which means for that to have certificate and stuff like that. So it can be a bit more difficult to cast your threat with the kernel mode K-logers. And for antivirus software, it's a bit more difficult to detect because analyzing drivers, it's a bit harder and to remove, it could be complicated since your driver is running with ring zero rights. Like on antivirus software. So to have something again more stronger than kernel mode one's keylogers, you can use hardware's keylogers. In fact this is the strongest way to have a keylogger. It's almost invisible since it's out of scope of antivirus software analysis. Why? Because antivirus software only analyze software which means files on the hard drive of the system. There is no antivirus for hardware. So it's almost impossible to detect because it's invisible. Hardware keylogers can be plugged directly to your machine for example or already inserted during the build of the hardware by the manufacturers. So it's sometimes very hard to detect with your eyes when you see your computer. Most of the time this type of keylogger are targeting attack. So it means it's not broadcast to the world's threat. And this is a bit complicated to use it because you need a physical access to the targeted machine. One is to plug the keylogger first and sometimes one more time when you need to retrieve information stored inside this keylogger. So the solution we propose today is a software library which is as low as possible in the sub-system of Windows trying to deal with all this type of keyloggers. And the goal is not trying to detect or remove keyloggers. It's the work of antivirus software and they are free to do it. But our goal is to scramble keystrokes in order to jamming keylogger present in the system if they are. So that's the goal of our system and we want to fight again keyloggers which have got many possibilities to be inside the system. For example when you use a user mode keylogger from a technical point of view you have many possibilities to create it. Among the possibilities you can use the Windows API function to retrieve message from the keyboard. For example we get asynchronous key state. Or you can register a hook to be notified when a key is pressed and a callback is called when a key is received on the system. And that's for user mode application keylogger. If you are a driver you are in the keyboard device stack and it depends on the altitude you are. You are just a question of priority. If you are an upper filter you are above the keyboard pressed driver and you use a predefined callbacks given by the keyboard class driver to be notified when they are received. But you can be lower, using a lower filter driver. In fact you are just above the high AT42 port driver. And you are notified before a keyboard class driver. And if you want to be a lower one more time again you can hook the keyboard interruption descriptor table, the e-accurate to replace the original keyboard interruption and using this new interruption to manage your keylogger and when it stays on the keyboard. So this is among all these possibilities. But this one, the last one of e-RQL hooking it's a bit more difficult to use on x64 system since the patch guard of Windows is tracking and checking the e-RQL validity of this table. So normally it shouldn't work on x64 system. So now about the solution we've developed. We've put the protection driver in the middle of the keyboard driver stack. So why? Why not in user mode? Just because any other application would have the ability to retrieve the key strokes as driver. So we could have put it as a higher filter driver but also by setting up a lower filter driver we will be able to retrieve the key strokes. And the final solution will be to hook the interruption descriptor table but with the patch guard it's not a regular solutions. So the only place to be the most efficient would be in the middle of the keyboard driver stack. So if we go a little into details on the keyboard driver stack when the key is pressed it generates an interruption which is handled by the interrupt service routine of the IAT42 port driver which checks the scan code and directly forward it to the protection driver. The protection driver encrypts the scan code if it needed and then gives it back to the IAT42 port driver. And then the normal processing is done. It's going to DPC and then the call of the keyboard class driver is done and the scan code is placed to the right of the system but encrypted. So about encryption, in fact the original idea we've got when we started the project was just to simply safer every key strokes received by the system. This is not very new solution or very sophisticated solution but if you try to do that it won't work as you expect. In fact what you observe is that very few key strokes are broadcast and received by the application of the system. So what does it mean? If you are looking for you will see that Windows only broadcasts key codes received and that it knows the world it means that unknown key codes are not broadcasted and are inhibited by Windows. So of course if you use Cypher in techniques it means you can use all possible outputs code using the keyboard code and inside this code a very small portion of this code are understandable by Windows. So that's why you receive so few key strokes for application. So it leads us to find another solution and a solution which only deals with non key strokes to be broadcasted on the system. And this solution to perform jamming uses the following ideas. The idea is to use substitution and permutation on a set of alloyed key strokes. That is to say of broadcastable key codes by Windows. We have constituted a white list of authorized key codes and we have worked with them on our algorithm to let the key code being broadcast by the system. In fact we will use the original stream Cypher to have a pseudo random number generator which is used to perform substitution and permutation operation on the alloyed set of key codes. And this set is shuffled for each key received on the system which makes it harder to perform cryptanalysis with statistical properties. And with this solution because it's just a permutation Cypher red key codes are broadcast on the system. That was the goal of our solution. Of course Kiloge will receive only random Z key codes. That means they have not the keys shared between the driver and the application which was our IPI to be able to decipher the received key codes and recalculate the original key strokes received on the system. We talked about the white list of authorized key code and for example just on screen is a keyboard and in green you've got the keys which are in the white list for us until now. It's our old key strokes. In fact that's enough to type a password because you've got characters, numbers, and symbols and these keys are all similar on old keyboard all over the world. In full range it's keys that could be included inside the white list but they don't directly mean something for the user like enter or remove or shift. It could be used to improve the number of possible passwords but until now it's not inside the white list. The white keys lastly displayed are not encrypted key because this key most of the time is something for the system encrypted something like control del doesn't make any sense because the user will lose control of his machine very soon. So most of this key are not used by password and most of them also depend on the keyboard manufacturers from a laptop to gamer keyboards there is many difference of keys. So to be as generic as possible we just choose the smaller set of aloe keys but in the future it could be much more larger. So to sum up in fact we've got algorithm from a theoretical point of view of the input of the algorithm you've got two possibilities. If the key stroke received is not in the white list it means we have not to make any encryption operation on it because it doesn't make sense. So it just starts with the system normally and it won't be touched by our application. And if the key stroke received is in the white list it means we need to cypher it so it receives encryption operation that is to say substitution and permutation and it follows the process described earlier that is to say it's output on the system. So more generally if you want to have a good idea so how to use the solution we've got an API which is in fact a library stored in a normal DLL which is used by a client application on the top left of the pictures. At the beginning the API is made to have the first step to be an exchange of key between the drivers and the application. Once the stream cypher secret key is sharing between the two parts we can start the protection that is to say when a key stroke is received the protection driver at the left will be notified of the key code it will perform the encryption operation and broadcast it to a keyboard cross driver which will send it to CRSS or take the application which will translate the code into Windows message. The client application will be able to decipher this code because they search the same key with the stream cypher but another application which can be a key logger will only see random data because it doesn't make sense for him. From that point once can say that it's not enough to make protection let's take an example. If someone's success to insert the driver levels and levels it means it will receive key strokes before our protection driver so it will be able to perform key logging operation without being disturbed by our protection driver which act after. So to give control measure to such program we have implemented many solutions first to detect our driver we first monitoring the registry checking that there is no driver installed levels and levels and then we monitor during the run time the keyboard driver stack to check that there is no driver inserted levels and us. At the end we perform protection again debugging techniques for example BLL injection stuff like that. The goal is to prevent application to get access to the working set of our protecting application to retrieve for example the stream cypher key shared between the application and the driver. So doing that we make filtering on process on the access or straight from the process access etc. At the end we use self cryptographic test to check the integrity of cypher subsystem between the driver and the application. The goal is just to prevent the altercation of cryptographic routines used by both sides and in addition it checks the good functioning of the system at the beginning before use. So is it working? Yep. So in fact just for demo purpose we have created a little application which has two threads one acting as a key logger and one acted as a protected application. First the application and the protected thread we try to make a connection between the drivers and itself sharing the key and after acting. So we will try to launch a video. It's very short. So at the beginning you've got the initiation and sharing the key that's made and then following you've got something type on the keyboard and at the left you've got the random data received by any key logger which held on the system which keystrokes are pressed but on the right you've got the good keystrokes received on the system by the protected application. That was the goal of our library. So to give back so now here is some ideas we had to act the protection system and to improve it. So for instance the keystrokes combination for instance when the user tip twice an A it would give an A or control A, give an A or whatever the user wants. Then we had polymorphic on screen keyboard. The idea between this is to fool all keyloggers even hardware. So in fact it will be a virtual representation of the real keyboard and the user would have to tip on its real keyboard according to the virtual representation and then of course the virtual representation will permute and change every keystrokes according to the output of the stream cipher of the current version of our protection. Then we have time based keystrokes for instance the user would have to put to press a key according to a timer displaying on its screen. Or like midi games, piano keyboards for instance press the key according to a certain melody such thing like that. And the last idea is to keep keystrokes in ring zero as we are developing it in ghost creep. So ghost creep is a fork of true creep developed in our labs in which we have removed UK USA algorithm and put houses. So the problem with ghost creep and so true creep is that the password is in week three why all the encryption system is done in ring zero. So it's really easy to retrieve the password with the DLL injection. So the idea is to lower all this procedure in kernel mode and in order to add a security layer. So in fact the keystrokes will be internally stored as soon as the password prompt is shown. So the keystrokes stored and then they are directly sent to the encryption function of the ghost creep. So that way if one wants to retrieve the password it will have to be in the kernel which is much, much more complicated. So the taste of the project for now it's a beta version so it needs more improvements and tests. Obviously it's true and open source so it's available on bitbuckets. You have the link below. And if one wants to participate we will be glad to welcome in the team. So thank you for your intentions. If you have any questions we may be around the beer or we are on peerless.com. Thank you again. We can detect it with monitoring of the registry of the keyboard driver class. So as you say there is two possibilities. The first one is to raise an alarm to the user and say there is something out in the system. This is what happened today. Removing it is possible but it's quite dangerous because you will broken the keyboard stack device and it could lead to bug check. So it's possible but it depends on the user option configuration. So yes, in fact it's not broadcast in ring 3 mode that is to say in application. So if you are an application you won't be able to see it. But if you are a driver you will be able to see it to see these unmeaning codes. So I think it's answer to your question. Okay, thank you. So thank you for your attention and we are available for beer or something stronger. Thank you.