A Practical Attack Against a KNX-based ... - Federico Maggi

A Practical Attack Against a KNX-basedBuilding Automation System

Alessio AntoniniPolitecnico di Milano

DEIBVia Ponzio 34/5

MilanIT

http://www.deib.polimi.it/[email protected]

Federico MaggiPolitecnico di Milano

DEIBVia Ponzio 34/5

MilanIT

http://[email protected]

Stefano ZaneroPolitecnico di Milano

DEIBVia Ponzio 34/5

MilanIT

http://[email protected]

Building automation systems rely heavily on general-purpose computers and communication protocols,which are often affected by security vulnerabilities. In this paper, we first analyze the attack surface of areal building automation system - based on the widely used KNX protocol-connected to a general-purposeIP network. To this end, we analyze the vulnerabilities of KNX-based networks highlighted by previousresearch work, which, however,did not corroborate their findings with experimental results. To verify thepractical exploitability of these vulnerabilities and their potential impact, we implement a full-fledged testbedinfrastructure that reproduces the typical deployment of a building automation system. On this testbed, weshow the feasibility of a practical attack that leverages and combines the aforementioned vulnerabilities.We show the ease of reverse engineering the vendor-specific components of the KNX protocol. Our attackleverages the IP-to-KNX connectivity to send arbitrary commands which are executed by the actuators. Weconclude that the vulnerabilities highlighted by previous work are effectively exploitable in practice, withsevere results. Although we use KNX as a target, our work can be generalized to other communicationprotocols, often characterized by similar issues. Finally, we analyze the countermeasures proposed inprevious literature and reveal the limitations that prevent their adoption in practice. We suggest a practicalstopgap measure to protect real KNX-based BASs from our attack.

cyber-physical systems security, building automation, KNX

1. INTRODUCTION

The development of information technology hasdeeply changed our lives, as well as the majorityof industrial processes. The future smart-greenhouses will be equipped with modern appliances(e.g., intelligent water, electricity and gas meters)with advanced computational and communicationcapabilities as in Chung-Ming Tung (2012). Thisprocess is driven, among other things, by theimperative need to better manage energy resources,which are limited due to a growth in demand, which isquickly saturating the supply capacity. Therefore, theneed to switch to smart digital systems, which wouldallow planned management of resources in civilianand commercial buildings, is now more evident thanever. For instance, a recent research of JunghoonLee and Gyung-Leen Park and Sang-Wook Kimand Hye-Jin Kim and Chang Oa Sung (2011)showed that smart power-consumption scheduling

can reduce the peak load in individual householdsand in the system-wide power transmission network.

Following this wave, vendors developed home andbuilding automation technologies that will soon playa central role in our daily activities. As reported by arecent market research of Paul Korzeniowski (2012),installations of building automation system (BAS) aregrowing significantly.

A BAS is composed of several sensors and actuatorsthat control equipments such as lighting, blinds,shutters, security systems, energy distribution,heating and air conditioning, or metering. In orderto transfer control data across different components,a common communication protocol (usually denotedas a "bus") is needed. The obvious advantage of aBAS is that the behavior of the controlled systemscan be easily modified via software reconfiguration,without modifications of the physical system-as itwas the case for more traditional systems. On the

c� The Authors. Published by BISL. 1Proceedings of . . .

A Practical Attack Against a KNX-based Building Automation SystemAntonini • Maggi • Zanero

other hand, this inherent flexibility opens the BAS,and the controlled system, to security weaknesses,which may seriously impact the physical surroundingenvironment.

Recent researches revealed serious security weak-nesses as in Wolfgang Granzer and Wolfgang Kast-ner (2011); Daniel Lechner and Wolfgang Granzerand Wolfgang Kastner (2008); Salvatore Cavalieriand Giovanni Cutuli (2009); Fritz Praus and Wolf-gang Kastner (2009), especially when these arenot physically airgapped from other communicationsystems present inside the building, or from the Inter-net. Some possible solutions to these vulnerabilities,mainly based on the introduction of cryptographicsolutions built with specific hardware as in DanielLechner and Wolfgang Granzer and Wolfgang Kast-ner (2008); Salvatore Cavalieri and Giovanni Cutuli(2009); Fritz Praus and Wolfgang Kastner (2009),have been proposed.

However, these works have a common shortcoming:they lack an experimental evaluation of the actualimpact of the described vulnerabilities, and similarlylack the evaluation of feasibility of the proposedsolutions.

Our analysis of the literature shows a lack ofexperimental verification of the actual vulnerabilityof BAS systems that can highlight the feasibility ofan attack and the possible impact, making it alsoeasier to suggest effective countermeasures, notnecessarily based on the use of specific hardwaresolutions.

The purpose of this paper is to comprehensivelyevaluate the attack surface of a network thatuses KNX as its basic protocol. We analyze itas the most representative protocol, but many ofour findings are likely to affect other protocolsas reported in Wolfgang Granzer and WolfgangKastner (2011), which analyzes the similar lack ofsecurity mechanisms in BACnet 1, LonTalk 2 andZigBee 3.

This paper makes the following original contribu-tions:

• We review previous research on the securityvulnerabilities and the possible attacks againstKNX systems;

• We show the practical feasibility of attacking aKNX system without requiring physical accessto any device; we describe our attack, and

1

2

3

.1;QHWZRUN

/$1

,QWHUQHW

5HPRWH�GHYLFHV

7&3�,3�URXWHU�ILUHZDOO

.1;QHW�,3URXWHU

/RFDO�GHYLFHV

$FWXDWRUV�H�J��OLJKW�VZLWFKHV�

6HQVRUV

.1;�VXE

V\VWHP

(76��PJPW��GHYLFH

Figure 1: A typical BAS deployment comprises a localdevice, a management device, a router connected to theKNX subsystem through the KNXnet/IP router, and remotedevices.

evaluate it on a testbed BAS which reproducesa real-world scenario;

• We analyze existing remediation approaches,describe their limitations and discuss theobstacles that prevent their use. We propose asimple mitigation based on the topology of thesystem installation.

2. SECURITY OF BUILDING AUTOMATIONSYSTEMS

In traditional power systems, operations (e.g.,control, actuation) are performed by the meansof switches or other physical interfaces. Suchswitches were limited to basic on/off functions, andadditionally, the controlled behavior would dependon the physical wiring of the system. In other words,changing the behavior of a switch or a load wouldrequire extensive re-wiring.

A BAS is fundamentally different, being composedof a network of sensors and actuators thatcommunicate with each other or with a centralcontrol unit via a bus connection. Actuators performactions (such as activating or deactivating loads anddevices on the physical side of the system, whichthey are connected to) in response, for instance, tospecific inputs on the sensors.

Consequently, a BAS differs from traditional systemsin the fact that it decouples its logic from the physicalpower wires, by adding a communication system(usually denoted as a “bus”) for the exchange ofinformation between the various devices. Amongother things, this results in the ability to add orremove features to a device acting via software atany time, with no need of rewiring.

So, a BAS is comprised of so-called “smartdevices” (i.e. sensors and actuators) and at least acommunication protocol.

2


Although several communication protocols exist forthe bus (e.g., Modbus 4, LonTalk 5, Zig-Bee, BACnet)KNX 6 is one of the most widely-adopted ones.

KNX is an international standard (ISO/IEC 14543/3),nationally implemented worldwide (e.g., UnitedStates AN-SI/ASHRAE 135, Europe CENELEC EN50090-CEN EN 13321/1, and China GB/Z 20965).

The widespread adoption of KNX is shown by thesupport of the major manufacturers of BAS devicesin the world 7 (e.g., ABB, Siemens and GEWISS).

Currently, many software houses and open-sourceprojects8 are developing end-user applications forKXN-based devices.

A typical configuration of a BAS connected to a LANand to the Internet is shown in Figure 1. There canbe several computers connected to the LAN, some ofthem used as management devices. In our case werely on ETS4 9, which is a manufacturer-independentconfiguration tool to design and program KNXhardware (e.g., actuators, sensors).

The KNXnet/IP router connects the TCP/IP and KNXnetworks.

Clearly, any device connected to the LAN is apotential weak spot for attacking the KNX network.

The spread of KNX-based applications, as well asthe variety and the importance of services managedby this system, make it important to assess itspotential security weaknesses.

Unfortunately, KNX implements only basic securitymeasures, as previous research has alreadyhighlighted.

2.1. State of the Art

Previous work identified lack of authenticationand encryption as the two main weaknesses ofKNX, and concentrated on proposing solutionsthat would prevent unauthorized access to theBAS. For instance, in Fritz Praus and WolfgangKastner (2009) and Daniel Lechner and WolfgangGranzer and Wolfgang Kastner (2008) the authorsaddressed the problem of securing the IP-levelconnectivity between different KNXnet/IP routers. Todo so, they introduced a specific hardware-softwaresolution, because KNX devices were not designed45

67

8

9

to implement any native cryptography algorithm, andthus they may lack the computational capacity torun standard encryption algorithms. This solutionhas two drawbacks: the development of nonstandardKNXnet/IP routers and the exchange of data in plainat the KNX network level.

In Salvatore Cavalieri and Giovanni Cutuli (2009),the authors proposed to implement a system basedon symmetric and asymmetric cryptography; theysuggested to do so without modifying the KNXstandard, but by introducing a “controller” whichwould be delegated to manage the keys. Theproposed solution simply moves the problem to thesecurity of the proposed controller.

While we analyze KNX as the most representativeprotocol, other protocols such as BACnet, LonTalkand ZigBee suffer from similar lacks in securitymeasures as shown in Wolfgang Granzer andWolfgang Kastner (2011). As claimed in WolfgangGranzer and Wolfgang Kastner and Fritz Praus(2010), BASs are exposed to several kinds ofmalicious attacks (e.g., denial of service, networksniffing, man-in-the-middle attacks, code injection,message replay). The risk of attack grows whenBASs are not isolated, but rather connected to othernetworks such as the Internet, as it often happens inreal cases.

In summary, we notice that the literature lacksexperimental research applied to real-world KNX-based systems. None of the aforementionedresearches attempted to carry out attacks on a realtestbed, or to practically evaluate countermeasures.

3. MOTIVATING EXPERIMENTS

The above analysis motivated us to implement arealistic KNX network, first to verify and confirm thepractical feasibility of the security findings describedin the literature, and secondly to systematize suchfindings in a real-world attack that shows the actualimpact of the lack of security mechanisms.

3.1. Experimental Setup

Using GEWISS components, we built a testbedthat (partially) reproduces a typical, if minimal, BASdeployment for building automation, as shown inFigure 2. It is composed of the following elements:

Contact Interface The GW90720 supports 4 inde-pendent inputs (e.g., buttons, switches, sen-sors), and can send appropriate commands toactuators.

Power supply The GW90709 is attached to theKNX bus.

3


*:��

*:��

*:��

*:�� *:��

Figure 2: KNX testbed detail.

Actuator 1 The GW90740 enables or disableselectrical loads through a 16A relay. It has4 output channels, which have a terminalconnected to a switch contact.

Actuator 2 The GW90542 has 2 channels forswitching and adjusting light bulbs or otheranalogical loads (e.g., servomotors).

KNXnet/IP router The GW90707 allows the com-munication between the TCP/IP and KNX net-work.

We describe the brand and version of the equipmentjust for the sake of completeness: the findings andattack described in the reminder of this paper are byno means limited to GEWISS components.

To configure our systems, we use ETS4 whichis a manufacturer-independent configuration tool todesign and program KNX hardware (e.g., actuators,sensors).

3.2. Protocol Reverse Engineering

Although KNX is an open standard, reverseengineering of the semantic of the packets thatare sent to the actuators is needed to practicallycarry out an attack. In our testbed, for instance, theactuators can be programmed via ETS4 only afterimporting the encrypted configuration files providedby GEWISS. These files contain the specific physicaland functional characteristics of the actuator, or thefunctions that can be carried out (e.g., on-off) andthe physical memory address where the softwarewrites EEPROM programming. The overall reverse-engineering approach presented hereby applies toother brands of KNX-based actuators.

Figure 5 shows the encapsulation of a KNX packetinto a TCP/IP packet. Specifically, in this example,besides the source and destination addresses, thepacket header identifies the actuator’s EEPROM

Figure 3: Wireshark cEMI data

Figure 4: Sniffing of actuator-reprogramming packages

area where the “data segment” payload is writtenwhen the actuator receives this packet.

In this example, our actuator had 4 channels,and only the first channel was enabled. We beginby sending a packet from the personal computerto the KNXnet/IP router and capturing the trafficwhich passes on the LAN. We used Wireshark withthe KNXnet/IP plug-in 10 to intercept the TCP/IPpackets originating from the ETS4 while sendingprogramming packets to the actuators. We repeatthe same procedure for other types of packets (e.g.,actuator programming, switching).

As detailed in Figure 3, the KNXnet/IP plug-in doesnot decode the KNX data segment. More precisely, itdoes not dissect the encapsulated common externalmessage interface (cEMI) packets as in EIB manual(1999)), which encode data such as the KNXdestination address or the datapoint types (e.g.,dimmer setvalues). This immediately confirmed thatpackets sent and received from the KNX networkare not encrypted as shown in Wolfgang Granzerand Wolfgang Kastner (2011). The specific type ofrouter in use, the KNXNet/IP GW90707, seems notto support data encryption (as specified by standardISO/IEC 14543/3) at all.

Figure 4 shows an example of a sniffing packetrelated to a programming message of the actuatorGW90740.10

4


We manually inspected the intercepted KNX packetsand identified the precise location and the semanticof the hex codes that reprogram and executecommands on the actuators. Table 1 shows a samplefragment with the bytes related to channels of theactuator highlighted in bold. The bytes meanthat the corresponding channel is disabled, whilemeans that the corresponding channel is enabled.

Using similar techniques, we managed to sendarbitrary packets to the other KNX devices in ourtestbed. As a result, we created a library of basicprogramming functions, by means of “template”packets. An example is shown in Listing 1, whichdetails a code snippet to enable or disable the firstchannel of the GW90740 actuator. Our library canbe extended by repeating the above procedure onother devices.

3.3. Password Protection

The transmission channel itself is insecure, evenduring reprogramming, as already mentioned inSection 3.2. This allows an attacker to interceptthe password sent in clear by ETS4 duringsetup. Indeed, as highlighted in Fritz Praus andWolfgang Kastner (2009), we verified that the onlyauthentication mechanism present in KNX is a 4-bytes password that the installer can send to allactuators using ETS4 during the setup phase. Thispassword is the same for all devices on the samesystem.

After the setup phase, the system requires noauthentication. In fact, any command (e.g., switchinga light on or off) is sent without sending anypassword to the actuators, even if actuators weresetup with a password. The password is onlyrequired to reprogram the actuators.

At a first glance, an attacker could obtain the 4-bytepassword with brute force. A closer look reveals thatin a real-world deployment this is more complex thanit appears.

Target addr Data segment

Table 1: Example of KNX packet analysis: 8 fragmentsof data segments extracted from 8 distinct KNX packets,each representing a specific programming instruction (inthis example, the highlighted bytes indicate the 4 channelsof the actuator). As a result, the actuator’s EEPROM willbe written from byte to (+4 bytes).

We evaluated the performance of a brute-forceattack to obtain the 4-byte password. To this end, weimplemented a simple random password generatorin C#, which forges an authorization packet throughthe A_Authorize_Request(key) packet, as detailedin Section 4.2. We measured that actuators takeabout one second to respond about the validity of arandomly-generated password. This is due to KNX’sinherent low speed, limited to 9600bps.

It is realistic to assume that an attack in real time ona single actuator/installation is not feasible.

4. A PRACTICAL ATTACK

The results of our experiments corroborate andstrengthen the findings detailed in Section 2.This motivated us to systematize such findings ina real-world attack that demonstrates the actualinefficacy of current security mechanisms and, mostimportantly, to stimulate the research community andindustry toward the development of better and usableprotection mechanisms.

4.1. Attacker Model and Limitations

We show the feasibility of a systematic attack,against a specific type of devices in the KNXnetwork, that requires no physical access to theBAS.

The attack is implemented by delivering anexecutable payload to any machine within the KNXsystem’s LAN. This is well within the capabilitiesof most attackers, and can be performed througha variety of means (e.g., email attachments,spear phishing, drive-by downloads, or portableUSB devices). The current prevalence of malwareinfections easily shows this. In addition, today’sincreased inter-connection between IP and non-IPnetworks (e.g., KNX) ensures higher chances for ourattacker model to fit real-world scenarios.

The attacker also needs to have access to atleast one device of the same type of each of theattacked devices in order to perform the protocol

Listing 1: hex code library example of actuatorchannel programming

5


Ethernet Internet Protocol User Datagram ProtocolUDP

Destination Header Source PortSurce Source Address Destination Port

Type (IP) DestinationAddress

LengthChecksum

Figure 5: KNX packet encapsuled into a TCP/IP packet.

reverse engineering described in Section 3.2. Thisis not a huge limitation in practice, as this is atargeted attack and not a generic, self propagatingmalware. Obtaining a test device is trivial, as theseare commercially available. Also, information on thetype of devices connected to a router can be easilyobtained as we show in Section 3.2.

The attacker goal is to be able to reset an arbitraryactuator to its default settings, take control of it, andin general disable the KNX-managed systems. Forall practical purposes, the final objective is to makethe end user(s) unable to control any BAS functionsuntil a complete reprogramming of the system takesplace.

4.2. Attack Description

We implemented our attack in a proof-of-conceptmalware written in C#, on top of the Calimero Javalibrary 11 to connect to KNX systems.

In order demonstrate the feasibility of a systematicattack against a specific type of devices in theKNX network without having physical access tothe BAS we devised a specific attack scenario. Inour attack, the attacker is able to reset to defaultoperating condition each installed actuator; the finalresult is to turn on all lighting (or in general, anyKNX- managed load present in the building). Inpractice, the end user is no longer able to controlthese functions until a complete reprogramming ofthe system takes place. The pre-requirement ofour scenario is that the attacker can deliver anexecutable payload to any machine on the sameLAN as the KNX system. This can happen throughany common vector, such as e-mail attachments,spear phishing, drive-by downloads, or infection ofportable USB devices. The pattern of attack, asshown in Figure 6, exploits the main vulnerabilitiesof KNX system, i.e., lack of authentication and lackof encryption in the transmission channel, in order toperform a combination of denial of service and man-in-the-middle attack. The workflow of the attack canbe summarized as follows:

• the initial compromise of a machine on the LANhappens through any vector, and a malware isdeployed on the machine;

11

Figure 6: Attack workflow.

• if the KNX system has not been programmedwith a password (see Section 3.3), themalware reprograms all of the actuators,deactivating the controlled systems and settinga password, which effectively prevents theinstaller to reprogram the system, forcing it tobe dismantled and sent back to the factory forresetting;

• if the system is protected by a password:– the malware simulates a system malfunc-

tion, e.g. by turning on and off the lights(since, as claimed in Wolfgang Granzerand Wolfgang Kastner and Fritz Praus(2010), operations are not authenticated);

– as a result of the malfunction, thesystem will be re-programmed using thepassword;

– as the password is sent in clear text, themalware can intercept it over the wire;

– after locating the password, the attackproceeds as if the system were notprotected.

KNXnet/IP Router Lookup. First, the malwarecreates a list of candidate KNXnet/IP routeraddresses by probing the whole local subnet forhosts that respond to messages.The malware then invokes the

6


Listing 2:

method of the Discovery class, which identifies thedevices connected to the KNX bus side of that router.

Password Protection Check. The malwaresends a packet as shown in Listing 2 bycasting the byte format request to cEMI. At thesame time, the malware starts a sniffing processto intercept the responses of the device. The

contains the defaultpassword , which is used if the system isunprotected.

An is sendback from the KNX device containing the level ofgranted access; if the response contains the hexcode (Listing 3) then the level of access allowsto write the memory of the device, otherwise theresponse contains the hex code , which meansthat the password does not allow write access on thememory. The is captured bythe malware using the sniffing process.

Password Sniffing. We implemented a sniffingmodule in C# that intercepts TCP/IP packets withKNX payload and reads the APCI field (see Figure5). Whenever an instructionis found, the malware decodes the passwordfrom the data segment and attempts a PasswordCheck to make sure that it is valid. To entice theuser into resetting/reprogramming the system, themalware can simulate a system malfunction (e.g.,by turning on and off the loads at random). Theseoperations are not authenticated. Confronted with amalfunctioning system, one of the troubleshootingsteps is to reset it using the original password, whichis sent in clear text from the ETS4 to the actuatorsand thus can be sniffed.

Device Reprogramming. After sniffing the pass-word, or if no password is set, the malware can seta randomized password which locks legitimate usersout. More importantly, it can reprogram the devicessuch that, from now on, they will execute arbitraryfunctions decided by the attacker.

4.3. Attack Evaluation

We deployed the malware in our testbed, and verifiedthat the cycle of operations works both with andwithout the password being set. As a result, the

Listing 3: Packet analysis of a memory write accessgranted response.

KNX-controlled equipments can be made unusableor otherwise reprogrammed.

4.4. Physical attack feasibility

Our attack can be carried out, alternatively, bygaining physical access to the KNX bus, as opposedto gaining logical access to a machine on the LAN.Although this may seem a stronger requirement, itis as simple as detaching a wall switch plate andconnecting a KNXnet/IP router to the exposed bus.Multiple KNXNet/IP routers can work independentlyon the same bus: The actuators and sensorscannot tell legitimate or malicious routers apart. Ifa password is set, it can be bypassed as explainedabove. Moreover, even if a password is set, maliciousinstructions can be injected onto the bus. This can beeasily automated by incorporating the routines of ourattack in a custom KNXnet/IP router.

5. COUNTERMEASURES

Existing work proposed to secure the IP side ofthe communication, as in Fritz Praus and WolfgangKastner (2009), or to implement a cryptography layerinside the actuators, as in Salvatore Cavalieri andGiovanni Cutuli (2009). These are not always viablesolutions as they require substantial redeploymentof existing hardware; even for newer hardware, amodification of the protocol would be ill accepted bymanufacturers due to increased production costs ofcomponents.

A potential stopgap countermeasure against remoteattack would be to redesign the deployment topologyof an existing IP-enabled KNX network, similarly totypical DMZ approaches as shown in Figure 7.For instance, a hardened (web) application couldbe exposed to the Internet, e.g. to allow remotecontrol of the system, connected back-to-back tothe KNX router which would then be shielded fromthe local LAN, without any need to tamper with thestandard itself. In this condition, a malware on theLAN would be unable to attack the KNX system,without exploiting the server or application, thusincreasing the attack cost.

7


/$1

.1;�VXEV\VWHP

%$6�VHUYHU

/RFDO�GHYLFHV

7&3�,3URXWHU�ILUHZDOO

Figure 7: Stopgap deployment example.

Another measure to increase attack difficulty can beto set an installation password, and then, in case ofmalfunctions or of any reprogramming, to isolate theKNX network from the LAN, using a dedicated, non-infected management device to reprogram the KNXdevices.

6. CONCLUSIONS

We analyzed the attack surface of a real KNXsystem and showed the actual impact of the lackof authentication and encryption solutions in theprotocol. To this end, we implemented a proof-of-concept malware able to remotely attacks a real-world home BAS and disable its functionalitiesentirely.

We also discussed how, although some solutionscan theoretically solve the issues, real-worlddeployments can realistically only be protectedthrough stopgap measures that do not address theunderlying weakness of the system.

Our conclusion is that, unless drastic improvementsare made to the protocol and to the devices onthe market, KNX cannot be secured against attacksled with physical access to the system, and canonly be made marginally resilient to remote, IP-based attacks. This means that the protocol, asof now, is unsuitable to handle security-criticalsystems such as alarms, and its deployment tohandle safety-critical systems such as lighting,power or environmental control should be carefullyevaluated, taking into account the aforementionedvulnerabilities, and at very least adopting airgappingor other stopgap measures such as the ones weproposed.

REFERENCES

Tung, C. (2012) Growing trend of network-based,smart green buildings towards automatic energy-saving performance: A study based on Advan-tech’s energy-saving system. International Journalof Automation and Smart Technology, vol.2, pag.2.

Lee, J. and Park, G. and Kim, S. and Kim, H. andSung, C. (2011) Power Consumption Schedulingfor Peak Load Reduction in Smart Grid Homes.Proceedings of the 2011 ACM Symposium onApplied Computing, pp. 584–588.

Korzeniowski, P. (2012) Commercial BUILDINGAUTOMATION PRODUCTS: TECHNOLOGIESAND GLOBAL MARKETS. BCC Research.

Granzer, W. and Kastner, W. (2011) Security Analy-sis of Open Building Automation Systems. Com-puter Safety, Reliability, and Security. (SpringerBerlin Heidelberg).

Lechner, D. and Granzer, W. and Kastner, W.(2008)Security for KNXnet/IP. Konnex Scientific Confer-ence.

Cavalieri, S. and Cutuli, G. (2009) Implementingencryption and authentication in KNX using Diffie-Hellman and AES algorithms. IEEE IndustrialElectronics Conference, pp. 2459–2464.

Praus, F. and Kastner, W. (2009) Securing IPbackbones in building automation networks. IEEEInternational Conference on Industrial Informatics,pp. 410–415.

Wolfgang Granzer and Wolfgang Kastner and Praus,F (2010) Security in Building Automation Systems.IEEE Transactions on Industrial Electronics, vol.57, pp. 3622–3630.

EIB (1999) Volume 2:Guide for Development. EIBAHandbook Series, release 3.0.

8

A Practical Attack Against a KNX-based ... - Federico Maggi

Documents

Transcript of A Practical Attack Against a KNX-based ... - Federico Maggi