master project analysis of unencrypted and encrypted wireless keyboard transmission

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 -



- 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])



- 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



- 4 -

Used paths

$GNURADIOROOT = /gnuradio-3.2.2

$GRCXMLBLOCKS = /usr/local/share/gnuradio/grc/blocks

$GRCPYBLOCKS = /usr/lib/python2.5/site-packages/grc_gnuradio



- 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.



- 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



- 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



- 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



- 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:



- 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.



- 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



- 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:



- 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



- 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



- 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



- 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



- 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



- 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



- 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])



- 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



- 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.



- 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.



- 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



- 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.



- 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



- 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



- 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



- 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



- 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.



- 30 -

Figure 15: Receiver flow graph in GRC



- 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.



- 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

}

}



- 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.



- 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



- 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



- 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).



- 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.



- 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.



- 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



- 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.



- 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.



- 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.



- 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’.



- 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



- 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



- 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.



- 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.



- 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.



- 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



- 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



- 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.



- 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.



- 53 -

Figure 26: Flowchart of how to establish an encrypted connection



- 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



- 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



- 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.



- 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.



- 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.



- 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.



- 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.



- 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’



- 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



- 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



- 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



- 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



- 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


keyupZeros



- 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


keypressZerosAccess code

Miller encoded data keyup

Access code

Resend Miller encoded data

keyupAccess code

Miller encoded shift keyup

Access codeResend Miller encoded shift

keyupZeros



- 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.



- 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).



- 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



- 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.



- 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.



- 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.



- 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.



- 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.



- 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

http://de.wikipedia.org/w/index.php?title=Datei:Cherry_keyboard_105_keys.jpg&filetimestamp=20060911153745

http://de.wikipedia.org/w/index.php?title=Datei:Cherry_keyboard_105_keys.jpg&filetimestamp=20060911153745



- 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



- 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

master project analysis of unencrypted and encrypted wireless keyboard transmission

Documents