Hello.  Okay.  So hi everyone and welcome to
track one.  Our talk here at 4:30 is how to secure the
keyboard chain.  And our speakers today are Paul
Amicelli and Baptiste David.  And here they are.
Please help me welcome ... 
(applause)...
     
>> So, hi everyone.  Thank you for coming.  His
name is Baptiste David and I'm Paul Amicelli.  We are from
France and we're working on computer security
luck.  Today we're going to talk about how
to secure the keyboard chain against a certain type of
viruses which are Quito gaps.  So this is under windows,
so sorry for the [indiscernible].  As we lost so much
time we will quickly see the security forms and then the main
idea of our work with some details and we will end up
with some ideas that we had to go further.
     So what's a Quito (ph.) gap.  Basically a Quito
gap are little piece of software or hardware or
whatever you want which is able to retract every piece
of information that can be typed on a keyboard.
Meaning for instance a credit card number, bank account
credentials and so on.
     They are underestimated since they can be anywhere
and they are barely invisible.  As you're going to see in
a few moments, they're quite easy to develop.
     So first we have to see how the Quito chain works.
There are three major stages, the hardware part.
Basically each key is a switch and when you press a key
it’s generating [indiscernible] with a code called a SAM (ph.)
code.  And this is handled by the channel part of the
operating system which consists of a set of drivers.
So we have the 1822 port which is the driver port.  It
basically handles every event on the keyboard and 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 [indiscernible] part
of the system.  Similarly like you do with windows
which converts the keyboard codes into a windowss
message which will be understood by all the
applications and the operating system itself.
     >> Well, when you want to make a -- you have many
ways to do it.  First you can create user mode one
which is quite easy to develop because it's quiet easy
to find codes on the internet.  The [indiscernible] is really easy to install, since it normally doesn't require any specific rights and it's very good piece of software which is able to do the job
requested.  Most of these keyloggers are well known
malware and can be detected by most of the antivirus
software on the market.  Because they are detected and
removable from the system and it's very efficient
but not so strong.  If you want something stronger you
can use cam ma (ph.) mode one.  The driver which is
inserted inside the keyboard driver sack, it's much
more efficient.  Because they have pre--- access to the
key strokes.  When the user presses the key strokes it's
first identified as a driver from the -- of windows.
This is why [indiscernible] not try.
     But we need to develop a driver and you need to
have specific rights like admin wise to install the driver on the
system and on 64 windows subset you need to assign
the driver and set figure [indiscernible] and things
like that.  It's more difficult to broadcast your --
[indiscernible].  And software is more difficult to
detect because analyzing drivers is a bit harder and
since the driver is running with zero right, like
[indiscernible].  So add something stronger, like in mode
one, you can use hardware -- it's a -- way to have a
keylogger.  Almost invisible since there is antivirus
software.  Antivirus software only analyze software on
the hard drive or the system.  There is no antivirus
for an address.
     So it almost impossible to detect because it's
invisible.  Hardware keyloggers can be directly to your
machine or already inserted during the birth of the
hardware by the manufacturers.  It's very hard to
detect with your eyes when you see your computer.  Most
of the times this type of targeted attack.  It's not
broadcast to worldwide threat.
     This is a bit complicated to use it because you
need physical access, one to plug in the keylogger
first and one more time when you need to retrieve the
information stored inside this keylogger.  So what we
proposed today is like a software library that is
possible in the subsystem of windows trained to deal
with all this.
     [indiscernible] not trained to detect or remove keylogger,
it's a work of continuous software and they're free to
do it.  Our goal is to scramble key strokes in order to
jamming keylogger (ph.) in the system.  That's the goal
of our system.  And we want to fight the keyloggers
that have many possibilities to be inside the system.
     When you use a user mode keylogger, you
have possibilities to create it.  One possibility, we
can use windows API function to retrieve message from
the keyboard.  For example we get a -- key state.  You
can release the [indiscernible] when the key stroke is
pressed and when a key is received on the system.
That's for user mode application keylogger.
     If you are a driver, you are in the keyboard
device -- and it depends, just a question
of priority.  If you're on -- you are able to keep
[indiscernible] directly and use the code backs -- by
the driver to be notified rooting to higher IRPs when they're
received.  You can use -- using the laptop driver.  A
[indiscernible] port driver and you are notified
before -- if you want to be -- one more time, again,
you can hook the keyboard into this table, to be, to
replace the original keyboard interruption using this
new interruption to manage your keylogger -- on the
keyboard.
     This is also a possibility.  This one, the last
one, it's more difficult to use on 64 systems since
windows tracks and checks the validity of the system.
This normally doesn't work on the 64 system?
     >> About the solution we developed.  We put a
protection driver in the middle of the keyboard driver
sack.  Why not in user mode?  Any other application
without the ability to retract the key strokes as
driver.  So we put it in as a higher -- driver but also
by setting up a lower -- driver, will be able to
retract the key strokes.
     And final solution will be to -- the table but
with the patch work it's not a regular, a regular
solution.  So the only place to be the most efficient
would be, is to be in the middle of keyboard driver
site.  So if we go into details on the keyboard driver
side.  When the key is pressed it generates a
interruption which is handled by the interservice 14
of the IHE42 -- driver.  Which detects the scan card
and directly forward it to the protection driver.
     The protection driver, the scan code if it's
needed and give them back to the IHE42 driver.  It goes
into a DPC and the -- of the class is done and it can
displace to the rest of the system that is encrypted?
     >> So about encryption, in fact the original idea
we got when we started this project was to sample
every -- when it was received by the system.  It's not
a very sophisticated solution.  But if you try to do
that it won't work as you expect.  What you see is very
few key strokes are broadcast and received by the
application of the system.  What does this mean?
     If you are looking for it, you will see that
windows only broadcasts P codes that it receives and
knows.  It means that unknown key codes with not
broadcasted and are inhibited by windows.  Of course if
you [indiscernible], it means you use all possible outputs, but
using the keyboard code and inside this code very small
portion of the code is understandable by windows.  That
is why you receive so few key strokes for the
application.
     So it leads us to find a solution.  A solution
which only gives none key strokes to be broadcasted on
the system.  And the solution [indiscernible] uses the
following ideas.  The idea is to use 62 bit -- on a set
of key strokes, broadcastable key codes by windows.
     We have -- the right key code and we have worked with them
on our algorithm to let the key code being broadcast by
the system.  We will use the original screen cipher
to -- random generator which is used to [indiscernible]
and a set of key codes.  And this set for HD receiver
on the system that makes other -- therefore -- with
[indiscernible] properties.
     And with this solution because it's just a
permutation, the code are broadcast on the system, that
was the goal of our solution.  Of course keylogger will
receive only key codes, that means they're not keys
shared between the driver and the application
we choose [indiscernible] to be able to decipher the received key
codes and receive the key strokes on the system.
     We talk about the [indiscernible] arise key code.
And for example just on the screen is a keyboard and in
green you've got keys which are in the white space for
us until now.  It's our old key strokes.  That's enough
to take a [indiscernible] because you have characters
and numbers and symbols and these keys are all --
[indiscernible].  In orange it's keys that can be
included in the white keys 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 -- but until now it's not [indiscernible] the
white space.
     The white keys are not -- because this key, most
of the time it's something for the system, something
like [indiscernible] doesn't make sense because the
user will lose control of the machine very soon.
     So most of these keys are much used by password
and most of them also depends on the keyboard
manufacturers from a laptop to -- keyboards, there are
many different keys.  So to be as generic as possible
we just use a smaller set of keys.  In the future it
could be much more larger.
     To sum up, in fact we have an algorithm from a
[indiscernible] point of view, the algorithm, you have
two possibilities.  If the key stroke received is not
in the white list that means we have not make any
encryption operation on its because it doesn't make
sense.  It just broadcast to the system and normally it
won't touch our application.
     If the key strokes we see is in the white keys,
that means we need to cipher it.  It receives
encryption operation [indiscernible] and it follows a
process described -- out put on the system.
     More generally if you want to have a good idea how
the use the solution, we have an API which is
[indiscernible] which is used by the application on the
top left of the picture.
     As the beginning the API is made to have the
first -- the key between the drivers and the
application.  Once the [indiscernible] is sharing
between the two parts we can start.  That is to say,
when a piece is received, the exploitation driver
[indiscernible] will be notified of the key code.  It
will perform the encryption operation and broadcast it
to the -- driver which will translate the code into
windows message.  The key application will be able to
decipher the code because they share the same key with
the stream -- [indiscernible] but the keyloggers we
only see random data because it doesn't make sense for
it.
     From that point, once you can see that it's not
enough to make -- for example.  If someone wants to
insert a driver, it means it will receive key strokes
before our -- drivers.  So it will be -- from operation
where there is disturbing [indiscernible].  So to
give -- to such a program, we have implemented many
solutions.
     First, to detect that driver, we're first checking
there is no driver [indiscernible].  And then during
the run time, the keyboard driver checks there is no
driver in -- lower than us.
     At the end, we perform protection again,
developing techniques, injection and stuff like that.
The goal is to prevent application from getting access
to the working sets of our protected application to
retrieve, for example -- key between the application
and the driver.
     So doing that we make filtering process on the --
shred from the process access, et cetera.
     At the end we use self-cryptography tests to check
the integrity of the system between the driver and the
application.  The goal is to prove the [indiscernible]
from both side and check the -- of the system before
beginning to use.
     Is it working?  So in fact just for the -- we have
created a little application which has two -- one
acting as a keylogger and one acting as a protected
application.  First the application and the protected
threat.  We try to make a connection between the
drivers.  Itself, showing the key.
     We will try to launch the video.  It's very short.
So at the beginning you have -- sharing the key.  That
is made.  And then following, you've got something
typed on the keyboard and on the left you have a random
data received by any keyloggers which -- on the system.
Which key strokes I pressed.  On the right you've got a
good key strokes received on the system.  That was the
goal of our library?
     >> So now here is some ideas we had to -- the
protection system and to improve it.  For instance --
combination when the user -- twice give an A or
whatever the user wants.  Then we add poly morphic
keyboards.  The idea of this is to fool all keyloggers
even hardwares.  It's a representation of the real
keyboards and the user will have to [indiscernible] on
the keyboard according to the VR representation.  And
the VR representation can change with every key stroke
according to the out puts of the stream cipher
[indiscernible] protection.
     We have ten base key strokes for instance to
use -- to press a key according to a time map on the
screen.  Or like -- general keyboards, for instance,
press the key according to a certain melody or
something like that.
     The last idea is [indiscernible] key strokes to
zero as we're developing it in industry.
     So go script is a [indiscernible] developed in our
labs in which we are removed the UK/USA algorithm.  The
problem is the -- why all the encryption system is done
in ring 0.  It's easy to retrieve the password with the
DLA injection.  The idea is to lower all the
[indiscernible] and in order to add a security layer.
In fact the key strokes will be internally -- as soon
as password prompt is shown.  The key stroke is stored
and directly sent to the encryption function of the
ghost script.  If one wants to retract the passwords it
will be to be in the channel which is much much more
complicated.
     The -- of the project, for now it's a bit
[indiscernible] needs more improvements and tests.
Obviously it's -- a label on the -- you have the link
below.  And if one wants to participate we will be glad
to welcome you in the team.
     So thank you for your attention.  If you have any
questions, maybe we'll have a round of beer or we're on
[indiscernible].com.  Thank you again.
...(applause)...
     >> (inaudible, question from the audience).
     >> We can't detect it with the monitoring of the
registry of the keyboard driver class.  As we said
there is two possibilities.  The first one is to raise
an alarm to the user and saying this is what happened
today.  Removing it is possible but -- because you will
broken [indiscernible] and it can lead to -- check.
It's possible but it depends on the user option
configuration.
     Yes.  Inside it's not broadcast in ring three
mode.  If you are in an application you won't be able
to see it.  If you're a driver you will be able to see
this meaning codes.  I think it's maybe the answer to
your question.  Thank you.  Thank you for your
attention.  And we are available for beer or something
stronger if you want.  Thank you.
     ...(applause)...