master project - studium an der hochschule ulm€¦ · master project analysis of unencrypted and...
TRANSCRIPT
Master Project
Analysis of unencrypted and encrypted wireless
keyboard transmission implemented in GNU Radio
based Software-Defined Radio
Matthias Fähnle
Markus Hauff
Advisor: Prof. Dr.-Ing. Frowin Derr
Hochschule Ulm
University of Applied Sciences
Institute of Communication Technology
Ulm, Germany
Winter term 2010/2011
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 1 -
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 2 -
Abstract
In an era where terms like WYSIWYG (what you see is what you get) have become proven,
the awareness of the countless radio frequency signals around us may have decreased.
Whenever we use a garage door drive with a remote control, use any kind of wireless
computer periphery or make e.g. use of wireless telecommunication, signals with individual
and private content are sent across the air interface. Dependent on used frequency ranges
and output power, theses signals can be captured up to some hundred meters e.g. when
using outdoor WLAN or GSM mobiles. Since those are well-known standards and normally
encrypted, they may be told “save” according to the used encryption algorithms.
But companies also often implement proprietary radio links which are not published. Since a
normal user is not involved in such topics, a sensitization only occurs if some awaking articles
are published. Especially where private data is entered or access to a building or a vehicle is
granted, non encrypted technologies or technologies with foreseeable sequence keys are a
huge risk. This fact builds the intention to our project.
Since modulation and line coding as well as frequency ranges vary from case to case, we
analyze a concrete wireless communication: Logitech Wireless Keyboards at 27 MHz.
To become quite independent from frequency bands, modulation and encoding, Software
Defined Radio (SDR) based on the Open Source project GNU Radio and the Universal
Software Radio Peripheral (USRP) were used. With a SDR architecture, signal processing can
be fully implemented in software and therefore is very flexible.
In seven chapters, this documentation provides a broad insight how to implement a full
software defined receiver and transmitter on arbitrary frequencies, with proprietary packet
structures and so far not implemented line coding like Miller coding. This document was
published to sensibilize users of wireless keyboards from Logitech with 27 MHz technology
and should only be used for educational purposes!
Ulm/Germany, February 2011
Matthias Fähnle ([email protected])
Markus Hauff ([email protected])
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 3 -
Table of contents
1. Tasks and targets of this project ...................................................................................... 5
2. Fundamentals ................................................................................................................. 7
2.1. SDR platform and basics ................................................................................................... 7
2.2. SDR block diagram ............................................................................................................ 7
2.3. Basics of cryptography ...................................................................................................... 8
3. Logitech 27 MHz wireless keyboard technology ............................................................. 11
3.1. Used signal frequencies .................................................................................................. 13
3.2. Modulation ...................................................................................................................... 14
3.3. Line code: Modified Miller code, Delay code ................................................................. 15
3.4. Frames ............................................................................................................................. 19
3.5. Frequency hops of the keyboard .................................................................................... 25
4. GNU Radio Receiver realization ..................................................................................... 26
4.1. Receiver chain ................................................................................................................. 26
4.2. Bit rate determination .................................................................................................... 26
4.3. Additional signal processing............................................................................................ 28
4.4. “Recover Miller Coding” block in detail .......................................................................... 31
4.5. GRC block “Packet Decoder” in detail ............................................................................. 33
5. Behavior of Logitech keyboard transmission path .......................................................... 41
5.1. Logitech Set Point software ............................................................................................ 41
5.2. Transmission sequence ................................................................................................... 42
5.3. Connection processes ..................................................................................................... 46
5.4. Encryption/Decryption .................................................................................................... 56
5.5. Differences between unencrypted and encrypted mode ............................................... 59
6. GNU Radio sender realization ........................................................................................ 62
6.1. “Keyboard Source” block in detail .................................................................................. 64
6.2. Sender implementation in GRC ....................................................................................... 64
6.3. GMSK MOD BLOCK .......................................................................................................... 67
6.4. Transmission power ........................................................................................................ 68
7. Attack scenarios ............................................................................................................ 69
7.1. Intrusion and disconnection ........................................................................................... 70
7.2. Intrusion, disconnection and establishing an unencrypted connection ......................... 74
8. Conclusion .................................................................................................................... 75
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 4 -
Used paths
$GNURADIOROOT = /gnuradio-3.2.2
$GRCXMLBLOCKS = /usr/local/share/gnuradio/grc/blocks
$GRCPYBLOCKS = /usr/lib/python2.5/site-packages/grc_gnuradio
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 5 -
1. Tasks and targets of this project
Looking at the system drawing in Figure 1 there is shown a typical scenario how to sniff a
wireless 27 MHz Logitech keyboard or even to get into the connection between receiver and
keyboard. The user normally works with his keyboard and types in even sensitive data.
Nearby, the intruder is placed with its equipment, the USRP and a laptop where the GNU
Radio software is installed. Then he can get the data of the keyboard and gain sensitive
information. Even more he can manipulate the connection and even send data itself to the
receiver and so control the computer remotely. Although the connection between the
keyboard and receiver can be encrypted, sniffing and even data manipulation should be
possible to realize.
That realization of the equipment described above, especially the implementation of the
receiver and sender functionality with GNU Radio, is the main task of this project.
Furthermore the software shall be able to fulfill the requirements in both possible kinds of
the connection the unencrypted and the encrypted one. Therefore first the functionality of
the connection between the two devices has to be analyzed. Then the behavior of the
connection in the unencrypted and encrypted mode needs to be known.
Summarizing the main tasks of the project:
Understanding the unencrypted and encrypted connection of Logitech
wireless keyboards.
Realizing a receiver with GNU Radio which is able to sniff data (unencrypted
and encrypted one) send by a Logitech wireless keyboard.
Realizing a sender with GNU Radio which makes it possible to send data to a
receiver and so to intrude to a existing unencrypted and encrypted
connection.
A successful realization of the tasks would make it possible to show the users of a wireless
keyboard that it is possible to sniff their data and to intrude into the wireless connection.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 6 -
Furthermore this hopefully has the effect of raising the awareness of the danger of the loss
of sensitive user data.
Figure 1: System drawing
Laptop with software GNU Radio
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 7 -
2. Fundamentals
2.1. SDR platform and basics
In principle, a universal applicable hardware serves as interface between the baseband and
the RF. The waveform of a transmitted signal is fully generated through software, as well as
a received signal is fully processed and demodulated within software algorithms. In SDR, the
processing power required for signal processing is sourced out to a universal host (PC).
An important benefit for industrial usage is the possibility to change complete processing
stacks or modulation schemes just with a software update. This also saves costs and time for
new hardware developments.
2.2. SDR block diagram
A universal SDR structure with the specific software (GNU Radio) and hardware (USRP/2) is
given in Figure 2.
Figure 2: Software-Defined Radio block diagram
In Figure 2, the Software-Defined Radio (SDR) structure is divided into three blocks. The left
one builds the RF frontend of the hardware which serves as interface to the analog RF
domain. In the second block, the intelligence of the hardware part is implemented, forming
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 8 -
the interface between the digital and the analog world. In the third block, the whole signal
processing is done - fully designed in software.
In the GNU Radio environment, Python and C++ are used as main programming languages as
well as a signal flow application called GNU Radio Companion (GRC).
For further fundamentals on USRP, USRP daughterboards, GNU Radio and the GNU Radio
Companion (GRC) please have a look at the “Bachelor Thesis Software-Defined Radio with
GNU Radio and USRP/2 Hardware Frontend: Setup and FM/GSM Applications” at [4] or
similar sources.
2.3. Basics of cryptography
This section tries to give a very short introduction in the area of cryptography. Basically, in
the cryptography the one who wants to send an encrypted message has the name Alice and
the one who is the receiver of the message is named Bob. Furthermore, there are two
different kinds of cryptosystems, asymmetric and symmetric systems. Below there is a brief
instruction into both of them although it turns out that in this project the encrypted
connection between a Logitech wireless keyboard and a receiver is a symmetric
cryptosystem.
2.3.1. Asymmetric cryptosystem
Asymmetric encryption is also known as public-key cryptography. In this kind of encryption
system every communication partner has a pair of cryptographic keys, a public encryption
key and a private decryption key. The public key is widely known whereas the private key is
only known by its user. The two keys are related mathematically but it is not possible to
derive another user’s private key from its public key.
A public-key encryption system can be described mathematically as follows:
If c = Epublic(m) then Dprivate(c) = m
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 9 -
in which E is the encryption function with the public key, D is the decryption function with
the private key, c is the cyphertext and m is the plaintext.
That means that D reverses the function of E. In other words:
Dprivate(Epublic(m)) = m
Figure 3 shows the principle of an asymmetric cryptosystem where Alice wants to send an
encrypted message to Bob. In this case the message confidentiality is ensured. Only the
receiver Bob is able to decrypt the message sent by Alice, nobody else.
Figure 3: Public-key (asymmetric) cryptosystem
Another way to use the asymmetric cryptosystem is that Alice encrypts the message with
her private key and everybody else can decrypt it with Alice’s public key. Then the
authenticity of the message is ensured. The message was definitely sent by Alice. That also is
called digital signature.
The public-key cryptosystem has some advantages:
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 10 -
There is no key interchange necessary.
There are very less keys needed. Every user only needs two keys compared to a
symmetric cryptosystem where n users need ( 1)
2
n n keys.
It is easy to add more users. A new user only needs two keys.
2.3.2. Symmetric cryptosystem
In this kind of encryption system the same key K is used for encryption and decryption. That
means that not only the cyphertext has to be sent over a channel. There has to be a key
interchange before that every partner knows what key is used. That is the most problematic
part of such a cryptosystem. It can be mathematically described as follows:
( )Kc E m
( )KD c m
in which E is the encryption function with the key K, D is the decryption function with the key
K, c is the cyphertext and m is the plaintext.
That means that D reverses the function of E with the same key. In other words:
( ( ))K KD E m m
Figure 4 shows the principle of a symmetric cryptosystem where Alice wants to send an
encrypted message to Bob.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 11 -
Figure 4: Symmetric cryptosystem
The disadvantage of a symmetric system, the key interchange, can be solved by using an
asymmetric system for the interchange. Then the secret key can be exchanged encrypted. In
this so called hybrid encryption system the advantages of both kinds of systems can be
combined. On the other hand the advantage of a symmetric cryptosystem is its higher
processing speed.
3. Logitech 27 MHz wireless keyboard technology
To get a first insight in the functionality of a wireless keyboard receiver system there is a
common description of how the two devices in the system work.
Receiver:
The receiver acts completely passive because the connection with a keyboard is
unidirectional. Only the keyboard is able to send data to the receiver, not vice versa. With
the connection to a personal computer over an USB interface, the receiver gets its voltage
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 12 -
supply. After pressing the connect button it waits a certain time for certain signals sent by a
keyboard which wants to connect with the receiver. These signals contain an individual
identification information of the keyboard, the keyboard ID. If the receiver gets such signals,
it remembers the ID in its memory. From this time, the receiver only accepts data, which
contain the remembered ID of the registered keyboard. All data having another ID will be
ignored. The used memory is non-volatile, so the connection between receiver and keyboard
will remain even if the computer is switched off. So, the connection does not have to be
initialized after a restart.
Keyboard:
The keyboard is the active part of the connection. It is able to send data to the receiver, but
it is not able to receive data itself. After inserting the batteries or pressing the connect
button, the keyboard transmits special sequences for a certain time. These sequences have a
defined format, which contains a keyboard ID amongst others. The initialization sequences
are for setting up the connection with a receiver nearby, whose connect button was pressed
before. So it waits for any initialization sequences of any keyboard. The keyboard itself does
not know if there is a connection to a receiver. It does not care whether any receiver is
getting its data or not but sends data after every keystroke respectively the initialization
sequence.
The following subsections go deeper into the technologies used in a wireless keyboard
system. To explain the technologies used in Logitech 27 MHz wireless keyboards, a
demonstration of the process of how to sniff the wireless interface and get the decoded
character is a good possibility. During this example, the used frequencies, modulation and
line coding are explained. Furthermore there is an explanation about the format used in the
messages sent from a keyboard and how a received signal can be interpreted. It should be
said that during this example the keyboard is not in encryption mode and sends its data in
plaintext.
Basically, the process of tapping the wireless interface until getting the decoded character
can be described in five steps as follows:
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 13 -
1. Received Signal at 27.095 MHz or 27.145 MHz
2. FSK-Demodulation
3. Miller Decoding
4. Bit stream
5. Key/Character
3.1. Used signal frequencies
With the aid of a receiving antenna, an USRP and the GNU Radio toolkit, it is possible to sniff
the air interface. In this project the used Logitech 27 MHz keyboards can transmit in the ISM
band at frequencies of 27.095 MHz and 27.145 MHz. After pressing the connect button of
the keyboard it sends status frames alternately on both available frequencies. Adjusting the
value of the center frequency of the spectrum to 27.12 MHz and the fast fourier
transformation in the software, one gets the receiving frequency spectrum shown in Figure
5. It is the green signal which is recorded in the peak hold mode, wherefore both frequencies
can be seen at the same time. The level of about 50 dB is not of relevance because it comes
from the internal signal processing of the USRP and the software.
At a keystroke, the keyboard only uses one frequency to send the according data frame to
the receiver. How the keyboard chooses with what frequency it sends is described later in
this documentation.
Figure 5: Received frequency spectrum (green signal received in peak hold mode)
27.145 MHz 27.095 MHz
Two symmetric peaks around the center
frequency are characteristic for FSK
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 14 -
3.2. Modulation
At the 27 MHz keyboard technology, the modulation ‘frequency shift keying’ FSK is
commonly used. The FSK modulation can be recognized in Figure 5 because of the two
symmetric peaks around the two center frequencies fc of 27.095 MHz and 27.145 MHz. The
distance between one center frequency and each of its peaks, also called frequency
deviation, is about 3 kHz. See Table 1.
fmin/MHz fc/MHz fmax/MHz
Low frequency 27.092 MHz 27.095 MHz 27.098 MHz
High frequency 27.142 MHz 27.145 MHz 27.148 MHz
Table 1: FSK frequencies
Assuming there is a key pressed on the keyboard, one of the signals at either the lower or
upper frequency, depending on which one is in use, is received and then FSK demodulated
to get the signal shown in Figure 6 below.
Figure 6: Receiving signal after FSK demodulation
That signal is low pass filtered to reduce the signals high frequencies. Those still can be seen
in Figure 6 on the signal. Next, there is a binary slicer to remove the remaining disturbances,
which results in a clear Miller encoded signal shown in Figure 7. The binary slicer creates a
High frequency disturbances
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 15 -
‘1’ level if there is a value greater than or equal to zero at its input and a ‘0’ level if there is a
value less than zero at its input.
Figure 7: Receiving signal after FSK demodulation and binary slicer, Miller encoded
In Figure 7 above one can see the preamble which is the long low-high series at the
beginning of the signal. Furthermore there are START and STOP, the longest pulses at about
t=53 ms and t=71 ms. Between them there are FRAMETYPE and FRAMECONTENT (explained
in 3.4).
To understand how to get the bits out of the FSK demodulated receiving signal the used line
code has to be mentioned. The line code used by Logitech 27 MHz keyboards is the Miller
code, also called Delay code, so, the signal in Figure 7 is Miller encoded. The following
section explains the Miller encoding and decoding rules.
3.3. Line code: Miller code, Delay code
3.3.1. Encoding
The information in a Miller coded is enclosed in the transitions of the signal level.
There are the following rules:
- A ‘1’ causes a transition from one level to the other one in the middle of the bit
period.
- A ‘0’ following a ‘1’ causes no transition.
START
T=3
STOP
T=3
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 16 -
- A ‘0’ following a ‘0’ causes a transition to the other level at the beginning of the bit
period.
For illustration of Miller encoding, see Figure 8.
Figure 8: Signal after Miller encoding
As can be seen, in the Miller signal are only three different times between the change of the
level. Referring to the time of one bit, meaning the definition that one bit time equals T=1,
the three resulting times are T=1, T=1.5 and T=2. These times also are used for Miller
decoding. The times between the transitions of the signal level hold the information about
the original signal. The signal level, high or low, is irrelevant for the decoding process.
3.3.2. Decoding
As mentioned before decoding of a Miller signal works with the interval between transitions
of the signal level. Due to the coding rules there have to be two bit ‘01’ in the original data
stream after the time T=2 in the encoded signal. The two other valid values of T, T=1.5 and
T=1 do not result in such a definite bit pattern because they depend on the previous times T.
Therefore, T=2 is the only possible start for decoding the Miller signal.
Having the first two bit of the original bit stream – ‘01’ decoded from T=2 – the
interpretation of the following times T is as follows:
0 0 1 0 1 1 1 0 0 1 1
T=1 T=1.5 T=2
T3=2
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 17 -
- T=1: the next bit is the same as the one before.
- T=2: the next two bits are ‘01’.
- T=1.5 AND the last bit is ‘0’: the next bit is ‘1’.
- T=1.5 AND the last bit is ‘1’: the next two bits are ‘00’.
There is also an example to show how decoding of a Miller signal works in Figure 9 below.
Figure 9: Example for Miller decoding
Applying the Miller decoding rules to the signal in Figure 7 there can be recognized that the
rules are violated at START and STOP since their length is T=3. This length is not a valid
length in a Miller coded signal because there are only T=1, T=1.5 and T=2 permitted. The
violation is necessary for detecting START and STOP of the frame. The preamble cannot be
used for this purpose because it can differ in its length at different keyboards. In addition the
number of bits between START and STOP can vary, depending on the keyboard and the
depressed key.
The signal in Figure 10 is used as the input signal for the Miller decoder. It begins at START
and ends at STOP each with T=3, meaning the first T=3 equals START the next T=3 equals
STOP. To get a valid combination of encoding and decoding, the decoded bit stream begins
with ‘0’ and not with ‘01’. This seems to be a modification of the Miller code by Logitech,
which differs to the standard Miller decoding rules in terms of the start of the decoding. For
Miller signal
T=2 T=1 T=1,5
T3=2
Original bitstream
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 18 -
the rest of the signal decoding is continued with the normal, valid decoding rules. After
recognizing T=3 of STOP the decoder stops.
Applying the Miller decoding rules to the Miller encoded signal in Figure 10 the result is the
decoded, original bit stream showed in the same figure at the bottom.
Figure 10: Bit stream (bottom) after decoding the received Miller encoded signal (top)
The same procedure is done with some lowercases of the German alphabet. Table 2 shows
each letter with its dedicated bit stream.
Letter Received bit stream
a 00000001000101011010100000011110100000
k 0000000100010101101010000110000110111
n 00000001000101011010100001000101110111
s 00000001000101011010100001011110111100
u 00000001000101011010100000111010111000
Table 2: Letters with its dedicated bit streams (unencrypted mode)
0 0 0 0 0 0 0 1 00 0 1 01 01 1 01 01 00 0 0 0 0 1 1 1 1 01 00 0 0 0 0
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 19 -
3.4. Frames
For understanding and interpreting the bit streams shown in Table 2, first the structure of
the different frames sent by a Logitech keyboard to the receiver has to be analyzed.
According to the patent [11] there is the following information.
Every time a key on the keyboard is pressed or some other information like status or data
information has to be sent to the receiver, the keyboard sends it in a so called frame. The
structure of such a frame which can be found in [11] is described in this section.
Basically, there are two different kinds of frames, the one of an unencrypted connection and
the one of an encrypted connection. In each case, different information can be transported
within a frame. It can contain status information of a keyboard as well as information about
what key was pressed on the keyboard. In the entire document, frames containing status
information are called status frames and frames containing information about a keystroke
are called data frames.
3.4.1. Frame structure of an unencrypted connection
Figure 11 shows the frame structure used in an unencrypted connection which slightly
differs from the one described in [11] but this structure is used by the keyboards
investigated in this project.
Figure 11: Frame structure of an unencrypted connection (according to [11])
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 20 -
The optional preamble is for synchronization purposes. START and STOP are markers to
identify the information. The real information is transported in the 32 bits of
FRAMECONTENT. DATATYPE distinguishes if the sent frame contains information about a
keystroke, resulting in a data frame, or a status message of the keyboard, resulting in a
status frame. The information which key of which keyboard was pressed is transmitted in
the fields SHORT_ID and DATA, which belong to FRAMECONTENT. SHORT_ID consists of
twelve bits and identifies the wireless transmitting keyboard with the keyboard ID. DATA
consists of eleven bits and contains the information what key was pressed. The ten bits
B0…B9 represent the different keys of the keyboard. The last bit of DATA ‘D’ shows if the key
is depressed or released. If D is ‘1’ the key was pressed, otherwise the key was released.
Furthermore, status messages also use the eleven bits of the DATA field. In the PROTECT
field are four bits for the CRC which means cycling redundancy check. The CRC is a checksum
who can detect accidental changes during the frame transmission.
3.4.2. Frame structure of an encrypted connection
Figure 12: Frame structure of an encrypted connection (according to [11])
The main differences to the unencrypted frame structure are only in FRAMECONTENT.
DATATYPE which indicates if the frame contains data or status information is two instead of
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 21 -
five bits in length. DATA is five bits longer and consists of 16 bits instead of eleven.
SHORT_ID and PROTECT are the same length and have the same task as in the frame of an
unencrypted connection. Figure 12 shows the structure of an encrypted connection.
More differences between the unencrypted connection and the encrypted connection in
terms of the frame structure and the transmission behavior can be found in chapter 5.5.
Back to the interpretation of the unencrypted bit streams showed in Table 2. With the
knowledge of frame structure used to send data, the bit streams can be analyzed. First, a
comparison of the streams results in the fact, that there are several bits which are the same
in every stream. The analysis begins with the D bit which says whether the key is depressed
or released. The streams were recorded while depressing the keys for a few seconds
meaning the D bit in each stream is the same value 1. In Table 2 this bit is bold and
heightened. Additionally considering the ten bits before the D bit makes all bits of DATA.
Twelve more bits before represent SHORT_ID which is the keyboard specific identification.
Since the same keyboard was used when pressing the keys, the keyboard ID is identical in all
streams. Again five more bits to the left belong to DATATYPE. The remaining bits until the
beginning of the stream are part of FRAMETYPE.
The four bits after D bit are the result of the cyclic redundancy check. The remaining bits
until the end of the stream are filling bits which are inserted if necessary. For what reason
they are added at the end is not clear. Investigations regarding the purpose of the filling bits
lead to the assumption that they are inserted that the STOP field has ‘1’ level and so that the
receiver is able to completely Miller decode the signal. Otherwise, after Miller decoding the
last bit of the PROTECT field might getting lost which would cause the refusal of the entire
frame.
The result of the bit stream analysis is structured in Table 3.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 22 -
Letter FRAMETYPE DATATYPE SHORT_ID DATA PRO-TECT
Filling bits
a 00000 00100 010101101010 00000111101 0000 00
k 00000 00100 010101101010 00011000011 0111 --
n 00000 00100 010101101010 00010001011 1011 1
s 00000 00100 010101101010 00010111101 1110 0
u 00000 00100 010101101010 00001110101 1100 0
Table 3: Interpretation of the bit streams with help of the frame structure (unencrypted mode)
As can be seen at the SHORT_ID, the same keyboard was used in this case since the
keyboard ID always is the same. Using additional keyboards and doing the same analysis
there can be recognized that the field DATA of the same letter is identical at all analyzed
keyboards. Therefore there is the assumption that there is a lookup table which contains the
bit stream for every key on the keyboard. This table is the same at every keyboard used at
least in this project, thus also probably at other 27 MHz keyboards of Logitech. The lookup
table entries of all 26 investigated letters are shown in Table 4 below. Since every key is
represented by seven bits, those left of the D bit are used.
Letter Bit stream Letter Bit stream Letter Bit stream Letter Bit stream
a 0011110 h 1000001 o 0000110 v 1111001
b 0000101 i 1111010 p 1000110 w 1001010
c 0111001 j 0100001 q 0001010 x 1011001
d 0111110 k 1100001 r 1101010 y 0011001
e 0101010 l 0010001 s 1011110 z 1011010
f 1111110 m 0100101 t 0011010
g 0000001 n 1000101 u 0111010
Table 4: Look up table, German lowercases
A more detailed description about the entire receiver realization can be found in chapter 4.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 23 -
3.4.3. Status frames
Status frames are sent from the keyboard to the receiver every time when some
‘organizational’ information shall be transmitted. They are of the same structure as data
frames with the exception that in the data field not a keycode is transported but status
information. To indicate a status frame, the field DATATYPE of the frame is used. There is the
information for the receiver if it has to treat the frame as a normal one (DATATYPE =
‘00100’) or as a status one (DATATYPE = ‘00110’).
Situations where status frames are needed are:
Process to establish a normal, unencrypted connection (also see 5.3.1)
After the batteries are inserted into the keyboard or connect button of the keyboard is
pressed it starts to send status frames on both frequencies to start a connection process
with a receiver automatically. To establish a connection, the connect button of the receiver
also needs to be pressed. The frames are alternately sent on both available frequencies for
about 20 seconds. If a nearby receiver is in waiting state, it will receive the frames and
accept the connection.
Process to establish an encrypted connection (also see 5.3.2)
When there is an unencrypted connection and there should be established an encrypted
connection, the user has to press the key combination CTRL+ALT+F12 and the connect
button on the keyboard to start that process. Directly after this combination was pressed,
the keyboard sends status frames to the receiver. They are necessary that the receiver
informs the Set Point software (see 5.1) that an encrypted connection is requested. If
receiving only the combination CTRL+ALT+F12 the receiver would interpret it as normal data
and not as a secure connection request.
Telling the receiver what frequency is used
That behavior could be seen during this project. Assuming the user does not press any key
within a certain time. At the keyboards in this project this time is only about three seconds.
At a keystroke after this time some keyboards send a status frame right before they send the
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 24 -
data frame. The status frame is sent right on the other frequency than the normal one is
sent. With this frame the receiver might get the information what frequency, the upper or
lower one, is used by the keyboard.
This behavior is not observable at all keyboards used in this project. Some do not tell the
receiver automatically what frequency is used like just described. That means if the receiver
is switched off and the keyboard changes its transmitter frequency, once the receiver is
switched on again, it will not get data from the keyboard anymore. So, maybe the receiver
does not need the information about the used frequency at all and is able to receive signals
on both frequencies without adapting its receiving path to that frequency.
3.4.4. Frame transmitting behavior
This short section describes how the data frames are sent. After pressing a key on a
keyboard it sends, depending on the mode, unencrypted or decrypted, the associated data
frame. The sending behavior differs depending on the keystroke. After one single keystroke
it sends the frame which indicates what key was pressed twice. See Figure 13 c). After key
release it also sends the frame which indicates the release twice.
On the other hand, if the key is pressed several seconds (Figure 13 b)), during that time only
the first keystroke frame is sent twice (Figure 13 c)). The following frames, also indicating the
keystroke are sent only once (Figure 13a)) not until the frame for the key release is sent. But
that frame again is sent twice. It seems that every time a change appears, the frame that
indicates the change is sent twice.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 25 -
3.5. Frequency hops of the keyboard
The keyboard can use two different frequencies to send frames to the receiver. These
frequencies are 27.095 MHz and 27.145 MHz. What frequency is used depends on the
keyboard. After the analysis of different keyboards regarding the transmitting frequency
there is the result that they change the frequency after every connecting process. After
pressing the connect button the keyboards send their status frames and end up with using
right the other frequency than they used before. The purpose of that behavior might be that
if two keyboards using the same frequency and interfere each other the user of one
keyboard establishes a new connection with right the other frequency. Then the
interference could be eliminated.
Figure 13: Transmitting behavior
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 26 -
4. GNU Radio Receiver realization
4.1. Receiver chain
First part of our receiver builds a GRC project from Benjamin Kendinibilir findable at [5].
Here are also some signal processing basics described relating to 27 MHz wireless keyboards.
As mentioned in chapter 3.1, the USRP center frequency is set to 27.12 MHz. Using two
frequency translation blocks, the low and high signal frequencies at 27.095 MHz and
27.145 MHz can be processed simultaneously. Afterwards, the signal is low pass filtered with
a cutoff frequency of 8 kHz to suppress jamming in higher frequencies.
After this, the power squelch blocks all input samples whose amplitude is below the given
threshold value. This prevents the quadrature demod block to interpret the noise as signal
input. Having demodulated and at the same time decimated the signal, it is once more low
pass filtered. This is useful since the demodulated signal may contain fast signal breakdowns,
which are much faster than the regular symbol rate and therefore surely disturbances.
4.2. Bit rate determination
The bit rate can be identified using several ways. One possibility is to measure the time of a
packet preamble. Since there are used exclusively bits with the symbol length T1, simply
calculating the average thereof gives a well bit-time result.
USRP Frequency Xlating FIR
Filter Low Pass
Power Squelch
Quadrature Demod
Low Pass
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 27 -
Figure 14: Bit time measurement on demodulated keyboard signal
This bit rate corresponds with the bit rate of 2.4 kbps mentioned in [7].
USRP ADC rate
USRP decimation 250
USRP rate = Quadrature Rate
Audio decimation 10
Audio rate
Logitech bit duration ≈ 417 µs
Bit rate
Samples per bit
Table 5: Sample rates and Logitech bit rate
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 28 -
4.3. Additional signal processing
Due to the low pass filtering after the demodulation, the output signal is smoothed and
freed of high frequency signal interferences. Now, a block called “Binary Slicer” is used to
reproduce a binary signal. This block creates a “1” on output for an input sample ≥ 0 and a
“0” for input samples < 0.
After the Slicer, a block called “Recover Miller Coding” is used. In this self written block, the
signal reconstruction according to Miller coding is done. This block uses hard coded
numbers of samples for every symbol length and therefore only works with the
corresponding sample rate of 25.6 kS/s. With this sample rate, a T1 is in average represented
by 10.6 equivalent samples followed by a change of the signal level (see Table 6).
Due to possible frequency offsets and clock instabilities, little tolerances need to be
accepted about the nominal T durations. So a T1 with ideally 10.6 input samples is also
accepted in the range from 7 to 13 samples. Also the other known T durations where
assigned to sample ranges as shown below.
Miller length Min (incl.) Max (incl.) Output of block
T1 7 13 00 or 11
T1.5 15 18 000 or 111
T2 20 25 0000 or 1111
T3 28 35 000000 or 111111
No signal 35 -
Table 6: Accepted quantities of input samples
Binary SlicerRecover
Miller Coding
Packet Decoder
Null Sink
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 29 -
All other input durations don’t produce out elements, so a symbol clock recovery is
implemented. Further information provided in chapter 4.4
The “Packet Decoder” block finally uses a correlator and framer to extract packets out of the
data stream for further processing. If the correlator has found the according T1 preamble
followed by a low T3, the data is passed to the framer. The framer checks the packet
structure as well as possible header information and cuts the packet to a predefined or
dynamic payload length. Since the Logitech packets have no header with information about
the payload length, the packet is dynamically framed after the high T3 sequence is found.
Having built the packet, the payload is put in a message queue. The further processing like
decoding and data analysis can therefore be implemented in python functions which run
independently from the sample rates of the flow graph. Further information provided in
chapter 4.5.
On the next page, the full GRC receiver flow graph is shown.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 30 -
Figure 15: Receiver flow graph in GRC
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 31 -
4.4. “Recover Miller Coding” block in detail
Because this signal processing block has to handle and affect the raw data samples directly,
it was implemented in C++. The fastest way to become a ready-to-built signal processing
block is to run the create-gnuradio-out-of-tree-project script in
/usr/local/src/gnuradio/gr-utils/src/python/ followed by the desired name of the
block. This creates a sample project in the current directory with the given project name
including python “qa”-files to check the blocks’ integrity and the XML files to create GRC
blocks.
Having a look at the lib path, there are two *.cc files called
YOUR_PROJECT_NAME_square2_ff.cc and YOUR_PROJECT_NAME_square_ff.cc as well as
the according header files. Main difference is that square_ff inherits from gr_block and
square2_ff inherits from gr_sync_block. While a gr_sync_block consumes every time all
given input items, a gr_block can additionally only consume a part of the incoming samples
but has to tell this number to the runtime system by calling
consume_each(noutput_items). Since we use all incoming samples, it’s possible to use the
square_ff sample. The _ff at the end of a block shows the data type of incoming and
outgoing samples. As we use characters as data type between the binary slicer and the
packet decoder, a byte in- and output makes more sense. This is represented by “b” (byte)
instead of “f” (float). Also the io signatures in the constructor needs to be set to
sizeof(char) as well as the data type of the *in and *out pointers which are likewise
called vectors. Finally, the in- and output formats need to be adapted in the according XML
files which are located in the projects grc folder.
All input samples are accessible by use of the *in pointer with a size of noutput_items. So
all processed input samples need to be written to out[] and finally the used size of out[]
needs to be returned at the end of the block. While processing a raw data stream, the size of
incoming data vectors depends on the used flow graph sample rates and can differ every
time the block is triggered. Since this size of incoming data may be much smaller than a
complete Miller encoded sequence respectively an input data vector can end in the middle
of a symbol, it is necessary to gain an insight how the last vector has ended.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 32 -
This can be done in GNU Radio by use of a history.
When the function set_history() is called in the constructor, the first history_size-1
input items from every input vector are the last ones already consumed from the last vector.
Also when not calling set_history() explicitly, the history variable from a gr_block is
historically set to 1. Since in this case the input_items also begin at element 0, the
history_size passed to set_history() will result in an array from 0 to history_size-2,
having history_size-1 elements.
Here, the history_size is set to 50, meaning that the first 49 elements from 0 to 48 from
the input_items will be already consumed history values. The new input_items are found
from element history_size-1 to noutput_items+history_size-2.
// search change in history; if not, stay
for (j = 1; j < history_size-1; j++){ // till 48
// HOLD
if (in[j]==in[j-1]) {
hold++;
}
// CHANGE
else {
hold=1;
}
}
A Miller coded T3 signal with the given bit rate and sample rate will maximal result in 35
equal level input values, so a history with 49 elements is absolutely sufficient. Finding two
equal consecutive values, the hold variable is incremented. Otherwise it is reset to 1.
Subsequently, the real new input values are walked through and checked for their
consecutive polarizations.
for (int i = (history_size-1); i <= noutput_items+history_size-2; i++){ // loop new values
// HOLD
if (in[i]==in[i-1]) {
hold++;
if(hold>59 && (hold%5==0)) { // decimate output rate about approx 5 when
out[k++]=0; // long equally polarized sequences occur
}
}
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 33 -
When a long equally polarized period is found, generally meaning no input signal, only for
every fifth bit is a 0 written to the out vector to decimate the stream.
After a polarization change of the input signal is found, it is analyzed for how many samples
the polarization was held. If this hold value fits into an appropriate symbol length for the
Miller code (T1, T1.5, T2 or T3) according to the used sample rate, symbols are written to the
out vector with twice of their recognized duration, resulting in two same symbols for T1 for
instance. This is done to become an integer number of output elements also if T1.5 occurs.
The polarization with which they were written to the out vector is changed for every full
symbol. Also the variable k is incremented for every written out element to know how many
samples were finally produced.
Due to possible frequency offsets and clock instabilities, little tolerances are accepted about
the nominal T durations. So a T1 with ideally 10 input samples is also accepted in the range
from 7 to 13 samples as explained in chapter 4.3. All other input durations don’t produce
out elements, so a symbol clock recovery is implemented.
At the end of general_work() all input elements were consumed and k output elements
are returned.
consume_each (noutput_items);
// Tell runtime system how many output items we produced.
return k;
4.5. GRC block “Packet Decoder” in detail
As mentioned above, the packet decoder uses a correlator and framer to extract packets out
of the data stream. This process has to be adapted particularly to the exploited packet
structure. After the framer, the further processing like Miller decoding and data analysis is
implemented in python functions which run independently from the sample rates of the
flow graph.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 34 -
The packet decoder block can be found in
$GRCXMLBLOCKS/blks2_packet_decoder.xml
<block>
<name>Packet Decoder</name>
<key>blks2_packet_decoder</key>
<import>from grc_gnuradio import blks2 as grc_blks2</import>
<make>grc_blks2.packet_demod_$(type.fcn)(grc_blks2.packet_decoder(
access_code=$access_code,
threshold=$threshold,
callback=lambda ok, payload: self.$(id).recv_pkt(ok, payload),
),
)</make>
Source code 1: blks2_packet_decoder.xml
Here we can see that it results in
$GRCPYBLOCKS/blks2/packet.py
An instance of packet_decoder() is created and passed to packet_demod_base()in the
end. In fact, a tiny step dependent on the block’s chosen output type is done in between
which sets the correct data type for _item_size_in.
As parameters, the access code, threshold value and the callback function are passed.
access code Sequence of 1's and 0's on which the correlator detects a packet. The
access code length is defined to be maximal 64 bit.
threshold Specifies how many digits from the access code may be false to also
correlate
callback In this case, called function after the unmake_packet() function from
_packet_decoder_thread() in packet.py is called
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 35 -
4.5.1. GRC Packet Decoder
class packet_decoder(gr.hier_block2):
def __init__(self, access_code='', threshold=-1, callback=None):
...
#blocks
msgq = gr.msg_queue(DEFAULT_MSGQ_LIMIT) #holds packets from the PHY
correlator = gr.correlate_access_code_bb(self._access_code, self._threshold)
framer_sink = gr.framer_sink_1(msgq)
#connect
self.connect(self, correlator, framer_sink)
#start thread
_packet_decoder_thread(msgq, callback)
Source code 2: packet.py
The most important tasks for the GRC packet_decoder class are to create a gr.msg_queue,
a gr.correlate_access_code_bb and a gr.framer_sink_1 as well as to connect these
blocks and start a packet decoder thread.
For the correlator, the original source code was used, findable in
$GNURADIO_ROOT/gnuradio-core/src/lib/general/gr_correlate_access_code_bb.cc
$GNURADIO_ROOT/gnuradio-core/src/lib/general/gr_correlate_access_code_bb.h
Between the correlator and the framer exists exactly defined data structure as shown below.
* output: stream of bits, 2 bits per output byte (data in LSB, flag in next higher bit)
*
* Each output byte contains two valid bits, the data bit, and the
* flag bit. The LSB (bit 0) is the data bit, and is the original
* input data, delayed 64 bits. Bit 1 is the
* flag bit and is 1 if the corresponding data bit is the first data
* bit following the access code. Otherwise the flag bit is 0.
*/
Source code 3: gr_correlate_access_code_bb.h
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 36 -
Also a verbose mode is implemented, which prints the incoming data bits and also if the
access code was found. For better understanding, this “function” can be activated by setting
the VERBOSE definition to ‘1’.
#define VERBOSE 0
Source code 4: gr_correlate_access_code_bb.cc
Changes in GNU Radio core files, which are built in C++, of course need to be recompiled.
One possibility is to rerun make and make install in
$GNURADIO_ROOT/gnuradio-core/src/lib.
Since connected from packet_decoder, the output data from
gr.correlate_access_code_bb are passed to gr.framer_sink_1.
Having found a correlation, the flag bit is set to ‘1’ according to Source code 3. This flag
represents the start of a new packet and represent the first byte after the access code. So
the framer starts directly with the packet data without access code.
4.5.2. Framer sink
The framer sink builds a packet out of the stream and writes it to the target message queue
passed from the packet_decoder. Because this block in normal is also responsible for
checking the header integrity and CRC as well as building the packet length, it needs to be
adjusted to our requirements.
The header is originally defined in the gr.framer_sink_1 block to be 32 bits long. First and
second 16 bits have to be exactly identical to be a valid packet. The lower 12 bits contain the
payload length, the upper 4 a whitener offset. When implementing a whitener offset,
identical packets result in different “on the air” data while being XORed with a specified
whitening array. This is a GNU Radio implementation and needs to be ignored in our case.
The structure of a Logitech packet differs from this format, because there is no header
containing data like payload length (see Figure 11).
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 37 -
This is why we don’t use the header functions header_payload()and header_ok() built in
gr_framer_sink_1.h. Knowing the Logitech packet structure we firstly set the maximum
packet length to 200 bits and cut it in gr_framer_sink_1::work() to its particular length
regarding the T3 end sequence.
static const int MAX_PKT_LEN = 200;
Source code 5: logitech_27mhz_transceiver_framer_sink.h
Furthermore the state STATE_HAVE_HEADER and the appropriate function
enter_have_header() are unnecessary.
The constructor calls the function enter_search()which initially sets the current d_state
to STATE_SYNC_SEARCH. Remaining in this state, all incoming input bytes are searched for
the correlator flag to be set (bit1 in LSB order).
Having found the flag in the input vector, the adjusted enter_have_sync() is called which
sets the new state STATE_HAVE_SYNC as well as several counters and the maximum payload
length. In state STATE_HAVE_SYNC 8 bits are shifted in a one packed byte. Furthermore the
d_held_one counter “searches” for the high T3 sequence which represents the STOP
sequence of a packet. If a full byte is filled, it is checked if the packet is finished. This applies
if the stop sequence is found, meaning d_held_one reaches 6, or the packet length is at
MAX_PKT_LEN. Since the message queue needs to be a multiple of 4, the packet is filled with
zeros until d_packetlen_cnt % 4 is 0. Finally a message built from d_packet is inserted at
the tail of the message queue with exact packet length. As from now, the Logitech data
packet is separated and processed independently of the remaining input data stream. After
having built the message, the function enter_search() is called which again sets d_state
to STATE_SYNC_SEARCH resulting in a new packet flag search.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 38 -
4.5.3. Packet decoder thread
The _packet_decoder_thread starts a daemon which continuously reads the message
queue and passes its content to packet_utils.unmake_packet() if available. Having
checked and handled the payload, it is passed to the callback function. The callback function
is according to blks2_packet_decoder.xml set to packet_demod_base.recv_pkt().
class _packet_decoder_thread(_threading.Thread):
def __init__(self, msgq, callback):
_threading.Thread.__init__(self)
self.setDaemon(1)
self._msgq = msgq
self.callback = callback
self.keep_running = True
self.start()
def run(self):
while self.keep_running:
msg = self._msgq.delete_head()
ok,payload=packet_utils.unmake_packet(msg.to_string(), int(msg.arg1()))
if self.callback:
self.callback(ok, payload)
Source code 6: packet.py
4.5.4. Miller coding
The principle of Miller coding was already described in chapter 3.3, so the python
implementation will not be explained in detail.
Our function miller_decode() expects the fitted payload as payload parameter. Payload
is a python list with type StringType which uses 8 bits per element. The variable sym_len
holds the quantity respectively the duration of the actual payload polarity. For every bit, a
length of 5 is used, resulting in a weight of 10 for a T1 symbol, 15 for T1.5 and so on. The
length is stored in the list arr[] and furthermore becomes independent of any polarity.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 39 -
The function str_to_binary() converts a character payload element to a new character
element in binary syntax e.g. “01011010”. Explained in chapter 3.3.2, the first decoded bit
has to be 0.
Now the list miller_dec_vect holds all decoded symbols which can be split according the
Logitech packet structure. For comparison and visualization of those elements a couple of
type conversions are used. Further information if needed will be found in the official Python
documentation.
The verbose mode prints out elaborate information which data packets were decoded and
which data content was found. Also it is analyzed if the received packet is encrypted, or if it
is a data packet or status packet.
Because Logitech uses a proprietary look-up table and not the ASCII codes to send their
keystrokes, the received data is looked up in our reverse engineered tables (section on Table
4).
If a known keystroke was found, the miller_decode() function returns the appropriate
ASCII character as well as ‘1’ as ok-parameter to tell the calling function that the decoding
was successful. If the keystroke was not found, both return values are set to 0.
The return values are passed backwards to the unmake_packet() function, to the
_packet_decoder_thread() and finally to the recv_pkt()function as callback given in the
GRC block Packet Decoder.
class _packet_decoder_thread(_threading.Thread):
...
def run(self):
while self.keep_running:
msg = self._msgq.delete_head()
ok,payload=packet_utils.unmake_packet(msg.to_string(), int(msg.arg1()))
if self.callback:
self.callback(ok, payload)
source code 7: packet.py
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 40 -
The recv_pkt() function processes the decoded ASCII characters. As described in chapter
3.4.4 Logitech resends every data packet dependent on how long a key is pressed or how
many keys are pressed.
Because recv_pkt() runs independent of the continuous data stream, an accurate time
measurement between the identified keystrokes can be implemented.
If a keystroke is realized within too short intervals, it is dropped as a sequence already sent.
If a keystroke was identified the first time, it is stored in the python list self.chars[]. At
the same time the current time stamp from time.clock() is stored in self.lasttime[]
with the identical index.
Every time a keystroke is found, the self.chars[] list is reviewed and the time interval
between the last occurrence and “now” is calculated. If the interval has a sufficient length,
the character will be processed. If not, a “Resent” is recognized and the entries for this
character in self.chars[] and self.lasttime[] are deleted. This is needed for fast
writers because it is possible to type faster than the implemented Logitech keystroke resend
if a key is permanently held.
Being sure to have found a valid character, the ASCII code is written to the file
/tmp/rec_27mhz_keys.txt with the function write_chr_to_file().
This file can be readout cyclic for example with the command
tail –f –s 0.1 /tmp/rec_27mhz_keys.txt
in a Linux shell.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 41 -
5. Behavior of Logitech keyboard transmission path
This chapter tries to describe all processes and behaviors that are seen and analyzed during
the project. It covers both connection modes the unencrypted and encrypted one. It covers
the connection processes, differences of the two modes, Logitechs encryption and
decryption process, information about the encryption key and the role of the Set Point
software.
5.1. Logitech Set Point software
There are different Logitech keyboard families which work in the 27 MHz band. Some of
them are able to activate an encryption mode, others are not. The analyzed Logitech
keyboards in this project have the possibility to go to an encryption mode but seem not to
have the encryption mode activated by default.
To activate the encrypting mode and so make the connection and transmission of data
secure, there is the possibility to use the Logitech software called Set Point. It is freeware
and can be downloaded from Logitech, for example. Since Set Point recognizes the used
receiver and keyboard, it allows the user to adjust the keyboard functions to his needs. It
provides functions to manipulate special keys, e.g. multimedia keys, to get the battery state
or to activate or deactivate certain keys of the keyboard. See a screenshot of the key settings
in Figure 16.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 42 -
Figure 16: Screenshot of the Set Point software: Hot key settings
Another important function of Set Point is the possibility to enable an encrypted connection
mode. Whether that is possible or not mainly depends on the functionality of the receiver
used. In this project there are receivers that have implemented an encryption mode and
others which have not.
5.2. Transmission sequence
5.2.1. Generation
After pressing the key combination CTRL+ALT+F12 followed by pressing the connect button
of the keyboard, the receiver generates a new transmission sequence. This sequence
consists of 16 characters at which the first eight characters contain the encryption key and
the second eight characters are for the confirmation purpose. They are used to check, if,
after the keyboard has got the key, forwarding the key to the keyboard was successful and
both the receiver and the keyboard are using the same key.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 43 -
After creating several different transmission sequences by pressing CTRL+ALT+F12 and the
connect button there is the suspicion, that not all available keys on the keyboard are used
for the transmission sequence. Because of looking at about 20 different transmission
sequences it seems, that only 16 different characters are used to create them. Those are 2 3
4 5 6 7 8 9 d f g h j k l s. Their placement on a keyboard can be seen in Figure 17. The reason
for the choice of these 16 letters and numbers may be the fact that on every keyboard the
positions of these keys do not vary. They are positioned at the same place no matter if the
layout is a German one or an American one, for example, whereas the position of the letter
‘y’ would vary.
Figure 17: Used characters for transmission sequence generation [2]
The characters consist of letters and numbers but not of special characters or capital letters.
In Figure 18 there are some examples of transmission sequences generated by the receiver.
Furthermore, in Figure 19 there is a screenshot of how a transmission sequence is displayed
on the screen and how the software asks the user to type in the sequence with the
keyboard. There the transmission sequence is called ‘code’.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 44 -
Figure 19: Transmission sequence displayed by the Set Point software
Total number of possible keys:
Every character of the key can be converted into four bits in binary notation. Thus, the key is
4 * 8 = 32 bits in length which means, that there are 232 = 4,294,967,296 different keys
possible.
Figure 18: Different transmission sequences
1. 25f3 g8sj lglk f79f
2. g964 k57h f778 957k
3. 72fk 53sj 9s3s f27s
4. h37d j4k8 82gs s382
5. 58h8 9d4f l663 6l89
6. g837 6hd5 2dgg k484
7. 2345 79kj ll74 fg89
8. 6j2s hd87 77dh hj93
9. 9sh8 kdj5 s4fj lds3
10. 5629 s73k kf77 897d
11. f758 2946 ffhk 887l
12. 5g9s jkhd dgf4 4796
13. 4356 g78j 65d5 2767
14. hfd8 5s7g ddgf 448g
Encryption key Confirmation characters
Transmission
sequence
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 45 -
5.2.2. Transmission sequence interchange
As already described in 2.3.2, the interchange of the encryption key is the main problem of a
symmetric encryption system. Both, the receiver and the keyboard have to know what key is
used. Otherwise, an encrypted connection is not possible, because encryption would use
another key than the decryption and the decrypted data makes no sense.
As already known is the key part of the transmission sequence and it is generated by the
receiver. Normally, from the encryption point of view only the interchange of the key itself is
enough to get a working secured connection. In the Logitech wireless system the
confirmation characters also have to be interchanged. Nevertheless, the remaining section
talks about the key which actually means the transmission sequence.
The key is created in the receiver. So, there has to be a way to inform the keyboard what key
was created by the receiver. Since the connection is unidirectional and neither the receiver
can send any data nor the keyboard can receive any data, it is not possible to transmit the
key automatically to the keyboard. Furthermore, even if a transmission to the keyboard was
possible, it would be very dangerous, because the transmitted data, respectively the key, can
easily be eavesdropped.
Therefore, another solution is used to tell the keyboard what key it has to use to encrypt its
data before transmitting it. The user of the keyboard has to do that. He acts as the
transmission channel which visually ‘sends’ the generated key from the receiver to the
wireless keyboard with the help of the Set Point software. The software informs the user
about what key is used for decryption by the receiver and the user types that key into the
keyboard. Thus, both the receiver and the keyboard know the same key. See Figure 20 to get
an impression of how the interchange works.
More details are described in 5.3.2 which explains the process to establish an encrypted
connection.
A related practice to this method of key interchange where the key is not transported over
the same channel that has to be encrypted is used in other applications, too. Thinking about
online banking, a so called TAN is necessary. The TAN, meaning transaction number, is a
single use password that the user needs to complete a money transfer. That makes online
banking much saver. To send the TANs to the user, a normal letter and not the internet is
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 46 -
used. Another example is to send a SMS to the user with an access code for an online
platform, for example, and not send the code over the internet.
In all cases, the necessary key to secure one channel or to identify something over this
channel is transmitted to someone who wants to do that over another channel.
Figure 20: Key interchange between receiver and wireless keyboard
5.3. Connection processes
5.3.1. Unencrypted connection process
Figure 21 shows the state flow of how to connect a keyboard with a receiver. The connection
is not secured meaning not encrypted.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 47 -
Figure 21: State diagram of an unencrypted connection
Assuming there is no connection after plugging in the receiver the user has to press the
receivers connect button. Then the receiver waits for about 30 seconds for status frames for
the initialization purpose of any keyboard. Thus, within that time the user has to press the
connect button of the keyboard or has to insert the batteries to the keyboard. In both cases
the keyboard automatically sends status frames on both available frequencies for a certain
time. These frames contain the keyboard ID in their SHORT_ID field already described in 3.4.
If the receiver gets the frames within its timeout, the connection should be successfully
established in the unencrypted, unsecured mode. The receiver stores the keyboard ID in its
non volatile memory. From this point it only accepts frames sent from the keyboard with
that keyboard ID.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 48 -
If the receiver gets no initialization status frames for whatever reason, there is no
connection between the receiver and a keyboard.
After pressing the keyboards connect button, it sends status messages as described above
on both available frequencies not only once but for about 20 seconds. Therefore it is also
possible to press the keyboards connect button first to make it sent those status frame and
next to press the receivers connect button. Then the receiver instantly gets the status
frames because the keyboard already sends them and connects with the keyboard. That is
another possibility to establish an unencrypted connection but the one described above in
Figure 21 is the normal one which even is described by Logitech itself.
5.3.2. Encrypted connection process
Once the connection between receiver and keyboard is in the unsecured, unencrypted
mode, it is relatively easy to get into the secured, encrypted mode. An encryption capable
receiver and keyboard and the Logitech Set Point software are necessary.
Figure 26 shows a flowchart and Figure 27 shows a kind of an interaction diagram of how to
get into the encrypted mode. It demonstrates how the three main parts of the system,
computer, receiver and keyboard have to work together. Assuming there already is an
unencrypted connection. Then the user has to press the key combination CTRL+ALT+F12 on
the wireless keyboard. It then sends a request to the receiver that an encrypted connection
is required. Then both the receiver and the keyboard wait for about 15 seconds. Within this
time the user has to press the keyboards connect button to continue. It is asked to do that
by the software seen in Figure 22.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 49 -
Figure 22: Set Point software used encrypted connection process
The keyboard then creates a new keyboard ID and sends status frames using that new ID to
the receiver. As soon as the receiver gets these status frames it calculates a so called
transmission sequence existing of 16 characters and stores it in its memory. This sequence is
send over the USB interface to the computer which can be seen in Figure 23 which is a
screenshot of the USB monitoring software ‘Device Monitoring Studio’ by HHD Software Ltd.
Figure 23: Transmission sequence sent over USB from receiver to computer
Transmission sequence over
USB interface
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 50 -
The Set Point software then displays it on the screen and asks the user to type in the
sequence with the keyboard. See Figure 24.
Figure 24: Set Point software asks user to type in code
The system existing of the receiver and the wireless keyboard waits about 75 seconds before
it stops the entire secure connection process and goes back to the unencrypted mode
meaning within that time the user has to type in the sequence. This happens in two phases.
During the first phase, the user types in the first eight characters. These characters represent
the actual encryption key of the system. The keyboard stores it in its memory. To prevent
the encryption key from being sent from the keyboard to the receiver in plaintext the
keyboard sends the character ‘*’ eight times at each keystroke. If it sent the key in plaintext,
the chance of eavesdropping would be much higher. The receiver actually receives the
characters ‘*’ in plaintext and forwards them over USB to the software. There they are
displayed in the according field. After typing in the transmission sequences first eight
characters the keyboard switches to encryption mode and uses the stored key to encrypt
every typed in character from this point. Next, the user types in the transmission sequences
last eight characters. They are used for validation of the entire process. Each of the data field
created after a keystroke is encrypted and sent in a data frame to the receiver by the
keyboard. The receiver decrypts every received frame with its stored key which should be
the same as the keyboards key. At the same time, although the receiver gets eight
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 51 -
characters it forwards eight times the character ‘*’ over USB to the computer. There they are
displayed in the according field.
Internally, the receiver compares the decrypted results with the former created
confirmation characters. If they match, both the receiver and the wireless keyboard seem to
use the same encryption key and the encrypted connection is established successfully. See
Figure 25.
Figure 25: Encrypted connection established successfully
If only one out of the eight received confirmation characters does not match the former
calculated one the receiver aborts the encrypted connection process and goes back to the
unencrypted connection.
Simultaneously to the receiver the keyboard also checks if the typed in confirmation
characters match. If not, it goes back to the unencrypted mode. This behavior suggests that
the encryption key and the confirmation characters are related somehow with each other.
There could be some mathematical correlation which makes it possible for the keyboard to
calculate if the confirmation characters fit to the key.
Researches during this project concerning the relation between the key and the
confirmation characters and how the check is done have not lead to a result so far.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 52 -
The following short section describes what happens if the keyboard waits for the input of
the transmission sequence after pressing CTRL+ALT+F12 and the connect button and the
user types in any characters as the transmission sequence but not the one calculated by the
receiver. According to 5.2.1 there are only 16 different characters used for the transmission
sequence calculation. If the user chooses random characters for the key and types them in
the keyboard, it accepts it and uses them to encrypt the keys pressed from this point.
The keyboard uses the next eight characters to check if those characters fit to the key. They
most likely will not fit together because the user does not know how the transmission key
and the confirmation sequence are related. Thus, the user types in any confirmation
characters. The keyboard recognizes that the typed in transmission sequence of the user is
not valid and cancels the encrypted connection process and goes back to the unencrypted
connection. The receiver also recognizes that the secured connection does not work because
it also does not know any data which were typed in the keyboard. Therefore the receiver
also cancels the entire encryption process.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 53 -
Figure 26: Flowchart of how to establish an encrypted connection
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 54 -
Figure 27: Interaction diagram of how to establish an encrypted connection
5.3.3. Connection behavior with two keyboards
Since it is important to understand the attack scenarios described later in 7 there is a short
description of how the receiver reacts if there appear two keyboards in the connection
process. Figure 28 shows it graphically. Assuming there is a secured connection between the
receiver and keyboard 1. By pressing CTRL+ALT+F12 there can be started another encryption
process which ends in an encrypted connection between the receiver and keyboard 1 except
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 55 -
that the keyboard uses a new keyboard ID but this is not harmful. After pressing the connect
button of the receiver it goes in waiting state and accepts status frames to connect with any
keyboard. If the receiver does not get any status frames, nothing happens and the secured
connection persists. But if the receiver gets status frames of another keyboard 2 which it
sends after its connect button was pressed, the receiver establishes an unencrypted
connection with keyboard 2.
Figure 28: Flowchart of the behavior with two keyboards
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 56 -
How to force the receiver to go in waiting state without pressing its connect button and
more about the possibilities to attack an encrypted connection remotely can be found later
in chapter 7.
5.4. Encryption/Decryption
According to the patent [11] of the manufacturer Logitech, encryption and decryption in the
keyboard work as described below.
5.4.1. Encryption process
For a graphical description of how to encrypt the data see Figure 29. Every key on the
keyboard is represented by its own keycode which is sent in the DATA field of a data frame
every time that key is pressed. That keycode consists of 8 bit. That means that 28 = 256
different keys can be represented. At normal keyboards there are approximately only 128
different keys which means, that the other remaining 128 keycodes are unused. Instead,
they are obviously needed for the scattering process. In this process after pressing a key, the
dedicated keycode is dispersed. In detail, the scattering process scatters the common keys
(e.g. “e”, “s”, space, …) among a set of more, unused keycodes. This makes it difficult to
identify a keycode, and so a pressed key, by its frequency. The histogram of the character
frequencies can be changed this way. The encryption module in the keyboard uses random
data to define what remaining keycode is assigned to a certain character in the scattering
process. Thus, the scattering process converts a keycode of 8 bits in length into multiple
keycodes also of 8 bits in length.
The next step is the expansion function. This function comes along with random like data
and the encryption key, normally of 32 bit in length. The key is typed into the keyboard by
the user before during the key interchange process. The expansion function enlarges the
scattered 8 bit keycode into a new 15 bit keycode. A detailed description of how exactly this
is done in the encryption module is not available, even not a simplified version of the
algorithms used.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 57 -
After that the dilution function combines the 15 bit keycode coming out of the expansion
function with another 15 bits selected from the bits of the encryption key. There also is no
description about the algorithm used in the dilution function.
The total length of the final encrypted keycode is 15 bit. The keycode is the only part in the
data frame which is encrypted. The other parts, e.g. the keyboard ID, are not encrypted.
Figure 29: Encryption block diagram (according to [11])
5.4.2. Decryption process
Figure 30 gives a basic overview of how to decrypt data. The decryption process can decrypt
the 15 bit keycode into the original 8 bit input keycode. To do so, the inverse processes of
the ones used in the encryption process are used [11]. The same encryption key which was
used to encrypt the keycode is used for decryption, too, which makes the entire system to a
symmetric cryptosystem.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 58 -
Figure 30: Decryption block diagram (according to [11])
For the publicity of the algorithms used in the different decryption blocks goes the same as
for the encryption blocks. In the research during this project there were no descriptions
about the functions and algorithms used in each block and therefore for the entire en- and
decryption process found. In the area of cryptography it is widely known that an algorithm
should be public. This is the only possibility to make sure that the algorithm is secure since
everyone can try to break it. If nobody is able to break it successfully, the algorithm
supposes to be secure. A system encrypted by a secret algorithm most likely is not as secure
as a system encrypted by a public one. This comes along with Kerckhoffs’s principle that the
security of a cryptosystem should only depend on a secret key and not on a secret algorithm.
Since the implementation of the blocks in this project seems to be secret there can only be
assumed how each block actually is realized. More about the assumptions can be found in
5.5 about the differences between the encrypted and decrypted mode. For the same reason
in this project it is not possible to implement a function in GNU Radio which decrypts
encrypted data. Therefore it is not possible to sniff encrypted data.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 59 -
5.5. Differences between unencrypted and encrypted mode
5.5.1. Frame structure
Figure 31: Frame structure of an encrypted connection (according to [11])
By comparing Figure 31 and Figure 12 there can be recognized that the DATA field in the
encrypted mode has 16 bit instead of only 11 bits in the unencrypted mode. The 16 DATA
bits come from the expansion function in the encryption module. The keycodes for each key
used in the unencrypted mode is expanded into 15 bits B0 – B14. Additionally there is the
pressed/depressed bit D at the end of DATA.
The field DATATYPE only has two bits instead of five. SHORT_ID and PROTECT are the same
length in both configurations encrypted and unencrypted. In total, the number of bits only
increases of two which means that FRAMECONTENT in the encrypted mode has 34 bits. With
a transmission time of about 417 microseconds per bit, the total transmission time is only
about 830 microseconds longer than in the unencrypted mode. The small difference in
transmission time allows the system to perform a high transmission rate even when
transmitting encrypted data.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 60 -
Table 7 shows the calculation of the number of bits of FRAMECONTENT:
# of bits Unencrypted Mode Encrypted Mode
DATATYPE 5 2
SHORT_ID 12 12
DATA 11 16
PROTECT 4 4
Total # of bits 32 34
Table 7: Comparison of number of bits of the field FRAMECONTENT
5.5.2. Frame transmission
In the unencrypted mode, no matter how often a key is pressed, the same data frame,
meaning DATA field, is sent by the keyboard. Even if there are different keyboards used, the
sent data frame always is the same except of course of the keyboard ID because of the
different keyboards and therefore also except of the PROTECT bits. The reason for that is
that Logitech seems to use for all its 27 MHz keyboards the same look up table which
contains the bit streams for the keys.
In the encrypted mode the sent bit streams differ even if the same key is pressed all the
time. The reason for that is that the encryption module makes sure that the unique keycode
of the look up table is manipulated according to the encryption flow chart shown in Figure
29.
Investigating the received encrypted frames, following results can be noticed:
1. The bit streams sent by pressing the same key several times are repeating.
2. The repetition distance of an identical bit stream is unsteady
3. The number of different occurring bit streams is not the same at different keys.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 61 -
Therefore, a systematic investigation of the sent encrypted keycodes is reasonable.
According to the patent [11] the scattering module of the encryption process disperses the
keycodes of common keys among a set of unused keycodes. This makes it difficult to identify
a keycode, and so a pressed key, by its frequency. That is the only known fact. All other
thoughts concerning the behavior and function of the encryption module are speculative.
A normal keycode consists of seven respectively eight bits. Assuming that uncommon letters
like the letter ‘q’ or ‘x’ are not dispersed, only their normal keycodes are manipulated by the
encryption module. Whereas if common letters like the letter ‘e’ or ‘t’ are dispersed a lot,
there is not only one keycode but much more depending on the scattering factor, which are
manipulated by the encryption module.
The relative frequency of the letter ‘q’ in a general English plaintext is 0.00095, which is
0.095%, whereas the relative frequency of the letter ‘e’ is 0.12702, which is 12.702%. To get
an idea how the scattering process disperses the keycodes of these letters, there is the
following experiment:
Assuming the keycode of the letter ‘q’ is not dispersed at all. Then the number of possible
different received bit streams is 128 because every one of the seven bit of the keycode can
be manipulated by the encryption process: 27 = 128.
On the other hand, assuming the letter ‘e’ is dispersed a lot because of its high frequency.
Then the number of possible different received bit streams is a multiple of 128. The
multiplication factor is the factor of the scattering process and so the number of additional
keycodes which are assigned to the letter ‘e’.
To check if the assumptions are correct, five different letters are analyzed. The keyboard
sends the encrypted data frames of every letter. Each of them is pressed continuously for a
about 20 minutes. The received encoded bit streams then are sorted to find out the number
of different occurring ones. The result is shown in Table 8. The higher the frequency of a
letter, the higher is the scattering factor and the more different keycodes are assigned to it
to make the histogram of the letters not useful to attack the encrypted connection. The
letter ‘q’ is seldom in an English text so the scattering factor is one whereas the letter ‘e’
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 62 -
occurs very often so its scattering factor is 17 times higher than the one of the letter ‘q’. The
letter ‘l’ has a medium value so it has the scattering factor of three.
So, the assumptions concerning the encryptions scattering function seem to be correct.
Letter Relative frequency
[6]
# of different occurring
bit streams
Scattering
factor
q 0.095% 128 (=128*1) 1
x 0.150% 128 1
v 0.978% 128 1
l 4.025% 384 (=128*3) 3
e 12.702% 2176 (=128*17) 17
Table 8: Investigation of the scattering function in the encryption process
6. GNU Radio sender realization
Figure 32: Structure of transmission chain
The sender is realized in 6 steps as shown above. First of all, there needs to be an input
interface with which the user can enter the keystrokes to send. After this, the packet
structure needs to be built. At first, the data type as well as the keyboard ID to which the
Capture keystrokes
Build packet structure
Calculate CRC
Miller Coding
GMSK Modulation
USRP
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 63 -
receiver listens to is put in a new packet. Then the 7-bit Logitech data sequence according to
the pressed key is looked up and appended to the keyboard ID. Finally, a CRC4 needs to be
calculated over the full data stream.
Having built the entire packet, it is line coded using the Miller encoding. Being encoded, the
sequence is passed to a GMSK modulator and transmitted with the USRP at the well defined
data rate and frequency.
Capture keystrokes:
Since the sending of key presses should also be done in real-time, a key press has to create a
new byte vector in the flow chart. This brings up a new challenge, because an external
triggered source is needed. Blocks like the UDP and TCP Sources in principle grant such
methods, but while using them, a permanent input needs to be given. If there are no packets
available on the UDP source port for instance, the GNU Radio executor stops the source
block permanently and ends up with the message:
gr_block_executor: source <gr_block_udp_source(1)> returned 0 from work.
We’re marking it DONE.
Using such a source makes only sense if a second program permanently sends UDP packets
right before the flow graph is started.
This is why a new source block called “Keyboard Source” was designed. This block gets the
typed characters from a file and flushes it after being handled. Additionally, an independent
GUI was built to write pressed keys in the accordant file. Also some additional key sequences
can be created just by clicking a button.
Figure 33: Keyboard source GUI
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 64 -
6.1. “Keyboard Source” block in detail
Capture of keystrokes is done within the text field. For every recognized key, an event is
triggered which analyzes the ASCII value and writes it to the file key_src.txt. Also the
deletion of characters is interpreted and handled as special ASCII control characters below
32. Before the output file is written, the GUI checks if the “Keyboard Source” block has
locked the file for reading. This is done by validating the existence of the empty file
key_src.read_lock. If the read lock file exists, a simple delay is performed. Regarding to
the tiny file sizes, the lock will be removed within milliseconds and not newly built as long as
the key_src.txt is empty.
After the delay has elapsed or generally if no lock file exists, the GUI also creates a lock file
called key_src.lock while writing. As long as this file exists, the “Keyboard Source” block
pays no attention to the transfer file key_src.txt. Having appended the received character
to this file, the lock file is removed and allows the “Keyboard Source” block to handle that
information.
6.2. Sender implementation in GRC
Figure 34: Sender implementation in GRC
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 65 -
6.2.1. Packet Encoder
See class packet_mod_base(gr.hier_block2) in packet.py
As input parameter of this class, the grc_blks2.packet_encoder is passed by the GRC
block. The packet_mod_base class connects its input to a message sink and starts an
encoder thread.
Equivalent to the decoder thread, the _packet_encoder_thread starts a daemon which
continuously reads the message queue. Since our “Keyboard Source” block generates “0”
only if no input is present, an incoming message sample is only accepted as valid if its order
is > 0. Having found a valid sample, it is passed to packet_encoder.send_pkt()by the
thread. Also the implemented key sequences are handled here. So e.g. the thread calls three
times send_pkt() to generate a CTRL+ALT+DEL.
if ord(payload) == 28: # "SENDING Ctrl+Alt+Del"
self._send(chr(17)) # define 17 as ctrl
self._send(chr(18)) # define 18 as alt
self._send(chr(19)) # define 19 as del
…
else:
self._send(payload)
Source code 8: logitech_27mhz_transceiver_packet.py
In packet_encoder.send_pkt(), the function packet_utils.make_packet() is called and
its output packet is written to the message queue connected to _msgq_out. This queue
builds the output of the encoder.
packet_utils.make_packet():
This function had to be implemented according to the Logitech packet structure. First, the
access_code is set to an alternating T1 sequence ending with a low T3 which represents the
start of a packet.
access_code = "110011001100110011000000"
Source code 9: logitech_27mhz_transceiver_packet_utils.py
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 66 -
In this function many string, hex, packet and binary data conversations are used which are
not explained in detail. Now a packet is build containing the data type, the keyboard ID, as
well as the data that should be sent. The accordant data to the passed ASCII payload is
searched in the lookup table the same way as it is done in the decoder.
Finally, the CRC4 needs to be calculated and appended to the data packet. After the packet
structure is complete, it needs to be Miller encoded in function miller_encode(). The
returned packet ends up with a high T3 followed by zeros to be a multiple of 8.
The keyup sequence is simply generated by setting the D-bit to 0. This sequence is appended
to the final data stream as showed below.
Figure 35: Final data stream to send for lower case letters
Capitals:
When the ASCII payload resides in the range of 65 to 90, a capital was pressed. Therefore an
extended sequence needs to be sent.
If no shift keyup is sent, the following data will be interpreted as capitals from Logitech
receiver.
Access codeMiller
encoded datakeypress
Access codeResend Miller encoded data
keypressZeros
Access codeMiller
encoded datakeyup
Access codeResend Miller encoded data
keyupZeros
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 67 -
Figure 36: Final data stream to send for capitals
6.3. GMSK MOD BLOCK
In USRP sink we use an interpolation factor of 500, because no huge data rate is necessary.
According to the DAC rate of USRP, the input sample rate of the USRP sink block is at
256 kS/s.
According to the measured bit rate (see chapter 4.2), we need approx. 2395 Bit/s. Therefore,
the “GMSK Mod” block should create 108 samples per bit.
Access codeMiller encoded shift keypress
Access codeResend Miller encoded shift
keypressAccess code
Miller encoded data keypress
Access codeResend Miller encoded data
keypressZerosAccess code
Miller encoded data keyup
Access code
Resend Miller encoded data
keyupAccess code
Miller encoded shift keyup
Access codeResend Miller encoded shift
keyupZeros
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 68 -
Since the packet encoder is designed to create two bits for a T1 symbol, the incoming data
contains two symbols per one desired output bit. This is why the Samples/Symbol parameter
of the “GMSK Mod” block has to be 54.
Since Logitech actually uses no Gaussian filtering, the BT product can be set to 1 or even
higher.
6.4. Transmission power
With the Basic TX board we measured the following transmission powers. A linear increase
of the amplitude by factor 2 raises the output power about 6 dBm until the output power is
limited at approx. -4 dBm by the DAC. This maximum corresponds with the maximal USRP
input amplitude at 32768 even it is discussible if such an output power is reasonable due to
possible clipping effects.
Signal amplitude send to USRP sink Measured output power
2 500 -26 dBm
5 000 -20 dBm
10 000 -14 dBm
20 000 -8 dBm
32 000 -4 dBm
Table 9: Measured Basic TX output power
In our transmission chain, we multiplied the input amplitude of maximal 1 in the “Multiply
Const” block by 5 000 to 10 000, resulting in an output power of 10 µW to 40 µW.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 69 -
7. Attack scenarios
With the software realized in this project it is possible to sniff data sent by a wireless 27 MHz
Logitech keyboard. If its connection to the receiver is not encrypted one is able to identify
what key was pressed on the keyboard. But as already described in 5.4.2 there is no
possibility in this project to decrypt data sent by the keyboard if it is in encrypted mode
because neither the encryption key nor the encryption algorithm are known. It makes no
sense to have the encrypted data but not the plaintext. It is not possible to decrypt the
received data and interpret it without actively influencing the encrypted connection to make
it unencrypted or just to intrude into the encrypted connection. Possibilities of how to do
that are described in this section.
Investigations concerning possible attack scenarios during this project yield the result, that
there are some weak points of the encrypted connection. The first one is the fact that in an
encrypted connection the keyboard sends its keyboard ID unencrypted. As described in
5.4.1, only the DATA field in the frame structure actually is encrypted but neither the
keyboard ID nor the depressed/released bit D. So, it is possible to listen to the encrypted
sent data with the USRP and get the currently used keyboard ID. That would be a passive
attack, seen in Figure 37 a). Furthermore, it is possible to send data with the USRP to a
receiver of an encrypted connection since it also accepts unencrypted frames. The only
requirement is that the unencrypted sent frames use the same keyboard ID as the encrypted
one. Then it is possible to send unencrypted data to a receiver although it is in the encrypted
mode which is an active attack, shown in Figure 37 b).
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 70 -
Considering the weaknesses mentioned above there are different attack methods:
The first one is intruding into an existing encrypted connection. The user can
continue working but the attacker is also able to send data to the receiver.
The second one is disconnecting the encrypted keyboard from its receiver. That
requires a successful intrusion to the connection before.
And the third one is cancelling the encrypted connection and forcing the user to
establish a new unencrypted one. But therefore the user should be not too
experienced in computers.
7.1. Intrusion and disconnection
Below there is a procedure which shows the first two attack methods meaning how to first
intrude into and later disconnect an encrypted connection. It is a combination of passive and
active attack:
b) Active attack a) Passive attack
Figure 37: Active and passive attack
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 71 -
1. Assuming that there is an encrypted connection between the receiver and the
keyboard which is to be interrupted.
2. As long as the sniffing antenna is close enough to the encrypted target keyboard it is
possible to receive the signals sent by it with the USRP.
3. Our software then picks the keyboard ID used by the keyboard of the encrypted
connection out of the received signals.
Until this point it is a passive attack. From point four it switches to an active one since data,
namely unencrypted one because the attacker does not know the encryption algorithm, is
actively sent to the receiver into the encrypted system by the attacker.
4. The attacker is now able to send data frames with the USRP to the receiver using the
sniffed keyboard ID of step three. That is possible because the receiver also accepts
unencrypted frames, as long as they have the same keyboard ID as the encrypted
ones.
Now it is possible even to manipulate, lock or shut down the computer. The intrusion is
successful.
For continuing the attack method and interrupt the encrypted connection the following
steps can be done. Figure 38 shows how to force the receiver to disconnect an encrypted
connection and establish a new unencrypted one with a new keyboard ID. The behavior is
the same as if there are two keyboards, which already is described in 5.3.3.
5. It is necessary to send status frames which use the sniffed keyboard ID to the
receiver with the USRP.
6. After getting the status frames sent in step five the receiver goes in the waiting state
and waits a certain time for any status frame of any keyboard. It is the same behavior
as if its connect button was pressed.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 72 -
7. The Set Point software installed on the attacked computer which is necessary to
establish an encrypted connection in the first place recognizes the status frames and
opens its encryption window. To avoid attracting the attention of the user it would
be useful to close the software at this point. Otherwise it shows the user how to
establish an encrypted connection again.
8. Next, during the receivers waiting time the USRP needs to send status frames, this
time using a new keyboard ID.
9. The receiver accepts the new keyboard ID, stores it into its memory and listens from
that point only to the new keyboard ID. Nobody else than the attacker and the
receiver know the new keyboard ID.
10. The encrypted connection is interrupted and it is not possible for the attacked user to
use its keyboard anymore.
11. For the attacker it is possible to send unencrypted data to the receiver with the
USRP. It is possible even to manipulate, lock or shut down the computer.
12. It probably would be helpful to close the Set Point software if not done before in step
six. Otherwise, if the user presses the receivers connect button and afterwards the
keyboards connect button with the hope that the connection will work again, the
software recognizes that the keyboard sends encrypted data. Thus, it opens a
window which asks the user to start the encrypting process to establish an encrypted
connection. If that happens, all previous steps would be useless and need to be
repeated.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 73 -
Figure 38: Attack scenario: disconnect an encrypted connection remote controlled
Note to step 6 and 7: These steps are not possible constantly. In about 80 percent of the
cases the receiver accepts our faked status messages sent by the USRP, in the other 20
percent it does not. The reason for that unrepeatable behavior cannot be analyzed during
this project anymore because of time limitations. Maybe the encryption status messages
need to have another special format than the normal status messages but this is only
speculative. A more detailed investigation could be follow in a separate project which also
tries to get more information about the encryption algorithm, for example.
Compare steps 5 and 6 of the
attack scenario above. They
cause the same reaction as
showed here.
Compare steps 8 and 9 of the
attack scenario above. They
cause the same reaction as
showed here.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 74 -
7.2. Intrusion, disconnection and establishing an unencrypted connection
The third attack scenario is to interrupt an encrypted connection and force the user to
establish a new unencrypted connection. Then it would be possible to sniff unencrypted
data sent by the keyboard.
The method to achieve that assumes that the user of the attacked wireless keyboard is not
experienced in computers too much.
Below there is the procedure which shows how to force a not experienced user to establish
an unencrypted connection after its encrypted one was disturbed:
1. The twelve steps described in 7.1 have to be done first.
After these steps it is only possible for the attacker to send data to the receiver. The
user is not able to send any data to the receiver anymore and the Set Point software
is closed.
2. The user is wondering why the connection is not working anymore.
3. Next, the attacker sends commands which create a message on the attacked users
monitor which says that the user needs to press CTRL+ALT+F12 and the connect
button on its keyboard to eliminate the connection disturbance. Furthermore the
message says that after pressing the keys the user should wait for about one minute.
That is necessary because once the keyboard is encrypted, the only possibility to get
it back to the unencrypted mode is to press CTRL+ALT+F12 and the connect button
and to wait about one minute.
4. After one minute the keyboard is in unencrypted mode. Then the attacker sends a
message with the USRP to the receiver which says that the user shall press the
connect buttons of the receiver, then of the keyboard. The result is the
establishment of a new unencrypted connection.
5. The inexperienced user is happy that the connection is working again at all and will
not start the encryption wizard of the Set Point software but continues to work.
6. As a result, the connection is and stays unencrypted and data can be sniffed with the
USRP.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 75 -
8. Conclusion
Considering the defined demands at the beginning of this project there can be summarized
that finally nearly all of them are met. The exchange of data at wireless 27 MHz Logitech
keyboards is not a secret anymore. With the realized system of USRP and SDR there is the
possibility to sniff the air interface of wireless 27 MHz Logitech keyboards and record the
received signal. In addition it can be processed and interpreted with signal processing and
analyzing software implemented during the project. That makes it possible to capture
sensitive data even in real time.
Realizing a sender enables to actively get into an existing receiver keyboard connection. It
allows to recreate user defined sending data that makes the receiver think it is from the
keyboard connected to it.
Since Logitech has a proprietary encryption process it is not possible to completely
reproduce it within a reasonable time. But there are known some details about parts of the
encryption process, e.g. the scattering process, and how the keyboard receiver system
behaves in an encrypted connection. And because of the now existing sender there is the
chance to intrude even into an encrypted connection. Furthermore, potential attack
scenarios are presented.
In the future there can be thought of projects which concentrate on the exact analysis of the
proprietary encryption process used in 27 MHz Logitech keyboards. Then it can be
concentrated completely on this topic, maybe with the help of an encryption expert.
Experiments and investigations can be done accurate to finally find out the secret encryption
algorithm. In case it will be found out, there can be thought of attacking an encrypted
connection with the brute force method to get the key and then decrypting the encrypted
data.
Additionally, there are possibilities to use the awareness in terms of the receiver and sender
realization with SDR and of the decryption problem to investigate security in other fields
where radio systems are used. Examples are the newer 2.4 GHz wireless keyboard
technology, other remote controls or WLAN systems.
However, with this project the basis for further investigations and analysis for whatever kind
of radio system is provided.
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 76 -
List of literature
1. Beutelspacher, Albrecht: Kryptologie – Eine Einführung in die Wissenschaft vom
Verschlüsseln, Verbergen und Verheimlichen, 6. Auflage, Friedr. Vieweg & Sohn
Verlagsgesellschaft mbH, Braunschweig/Wiesbaden, 2002.
2. Cherry keyboard 105 keys, [Online] [Cited: 01 11, 2011.]
http://de.wikipedia.org/w/index.php?title=Datei:Cherry_keyboard_105_keys.jpg&filetim
estamp=20060911153745
3. Ertel, Wolfgang: Angewandte Kryptographie, 2. Auflage, Fachbuchverlag Leipzig im Carl
Hanser Verlag, 2003.
4. Fähnle, Matthias: Bachelor Thesis: Software-Defined Radio with GNU Radio and USRP/2
Hardware Frontend: Setup and FM/GSM Applications, Hochschule Ulm, 2010.
5. Kendinibilir, Benjamin: 27MHz Funktastatur und –maus auslesen, [Online] [Cited: 11 03,
2010.]
http://wiki.techstories.de/display/Hobbys/27Mhz+Funktastatur+und+-maus+auslesen
6. Lewand, Robert Edward: Cryptographical Mathematics, THE MATHEMATICAL
ASSOCIATION OF AMERICA, 2000.
7. Logitech: 2.4 GHz Wireless Technology – A Logitech white paper, [Online] [Cited: 11 17,
2010.]
http://www.logitech.com/images/pdf/emea_business/2.4ghz_white_paper.pdf
8. Pramateftakis Michael, Spitz Stephan, Swoboda, Joachim: Kryptographie und IT-
Sicherheit – Grundlagen und Anwendungen, 1. Auflage, Vieweg + Teubner Verlag,
Wiesbaden, 2008.
9. Schmeh, Klaus: Kryptografie – Verfahren, Protokolle, Infrastrukturen, 3. Auflage,
dpunkt.Verlag, Heidelberg, 2007.
10. Schneider, Bruce: Angewandte Kryptographie, Pearson Studium, 2006.
11. US Patent 7224801: Wireless Secure Device, 2007, [Online] [Cited: 10 29, 2010.]
http://www.freepatentsonline.com/7224801.html
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 77 -
List of figures
Figure 1: System drawing ........................................................................................................... 6
Figure 2: Software-Defined Radio block diagram ...................................................................... 7
Figure 3: Public-key (asymmetric) cryptosystem ....................................................................... 9
Figure 4: Symmetric cryptosystem ........................................................................................... 11
Figure 5: Received frequency spectrum (green signal received in peak hold mode) .............. 13
Figure 6: Receiving signal after FSK demodulation .................................................................. 14
Figure 7: Receiving signal after FSK demodulation and binary slicer, Miller encoded ............ 15
Figure 8: Signal after Miller encoding ...................................................................................... 16
Figure 9: Example for Miller decoding ..................................................................................... 17
Figure 10: Bit stream (bottom) after decoding the received Miller encoded signal (top) ...... 18
Figure 11: Frame structure of an unencrypted connection (according to [11]) ...................... 19
Figure 12: Frame structure of an encrypted connection (according to [11]) .......................... 20
Figure 13: Transmitting behavior ............................................................................................. 25
Figure 14: Bit time measurement on demodulated keyboard signal ...................................... 27
Figure 15: Receiver flow graph in GRC ..................................................................................... 30
Figure 16: Screenshot of the Set Point software: Hot key settings ......................................... 42
Figure 17: Used characters for transmission sequence generation [2] ................................... 43
Figure 19: Transmission sequence displayed by the Set Point software ................................. 44
Figure 18: Different transmission sequences ........................................................................... 44
Figure 20: Key interchange between receiver and wireless keyboard .................................... 46
Figure 21: State diagram of an unencrypted connection ........................................................ 47
Figure 22: Set Point software used encrypted connection process ........................................ 49
Figure 23: Transmission sequence sent over USB from receiver to computer ....................... 49
Figure 24: Set Point software asks user to type in code .......................................................... 50
Figure 25: Encrypted connection established successfully ...................................................... 51
Figure 26: Flowchart of how to establish an encrypted connection ....................................... 53
Figure 27: Interaction diagram of how to establish an encrypted connection ....................... 54
Figure 28: Flowchart of the behavior with two keyboards ...................................................... 55
Analysis of unencrypted and encrypted wireless keyboard transmission
implemented in GNU Radio based Software Defined Radio
- 78 -
Figure 29: Encryption block diagram (according to [11]) ......................................................... 57
Figure 30: Decryption block diagram (according to [11]) ........................................................ 58
Figure 31: Frame structure of an encrypted connection (according to [11]) .......................... 59
Figure 32: Structure of transmission chain .............................................................................. 62
Figure 33: Keyboard source GUI ............................................................................................... 63
Figure 34: Sender implementation in GRC ............................................................................... 64
Figure 35: Final data stream to send for lower case letters .................................................... 66
Figure 36: Final data stream to send for capitals ..................................................................... 67
Figure 37: Active and passive attack ........................................................................................ 70
Figure 38: Attack scenario: disconnect an encrypted connection remote controlled ............ 73