A Survey on Security Considerations forMicrocontrollers in Traffic Light Networks

(1)

Degree project in Computer Science Second cycle

A Survey on Security Considerations for Microcontrollers in Traffic Light Networks

Johan Cronsioe

(2)

A Survey on Security Considerations for Microcontrollers in Traffic Light Networks

JOHAN CRONSIOE

Master’s Thesis at CSC Supervisor: Douglas Wikström

Examiner: Johan Håstad

TRITA xxx yyyy-nn

(3)

(4)

Abstract

This thesis was written at the Computer Science Department at Uni- versity of Idaho, Moscow, Idaho, USA.

The university is collaborating with the Department of Transporta- tion (DOT) and the Idaho Transportation Department (ITD), to improve the safety of traffic intersections during bad weather conditions.

The purpose of the thesis is to survey the techniques available for securing the connection between a microcontroller that adjusts the traffic light controllers and a weather data server, using the Rabbit RCM4300 microcontroller and the Juniper services gateway SRX210. For this reason, devices located in the DOT/ITD control network, which is isolated and not connected for access from the Internet, need to communicate with external servers. The aim is to find a solution that is secure enough for DOT/ITD to allow the microcontroller to be connected to their network and letting it access the server over the Internet.

The relevant security capabilities of the devices were investigated, tested and then analyzed with respect to resistance to attacks and ease of configuration and maintainability.

The selected methods were Internet Protocol Security (IPsec), Trans- port Layer Security (TLS), Deep Packet Inspection (DPI). While the security was deemed sufficient using either IPsec or TLS, the ease of implementation and maintainability varies. Due to the risk of bugs in both protocols and software, keeping up to date with their security issues is crucial.

(5)

Referat

En Studie om Säkerhetsbeaktanden för Mikrokontroller i Trafikljusnätverk

Denna uppsats skrevs på avdelningen för datalogi vid University of Ida- ho, Moscow, Idaho, USA.

Universitetet sammarbetar med Department of Transportation (DOT) och Idaho Transportation Department (ITD), för att förbättra säkerhe- ten vid gatukorsningar vid dåliga väderförhållanden. Syftet med uppsat- sen är att undersöka vilka tekniker som finns tillgängliga för att säkra anslutningen mellan en mikrokontroller som justerar trafikljuskontroller- na och en väderdataserver, genom att använda mikrokontrollern Rabbit RCM4300 samt brandväggen Juniper SRX210. Av denna anledning mås- te enheter i DOT/ITDs kontrollnätverk, vilket är isolerat och ej anslutet för åtkomst till internet, kunna kommunicera med externa servrar. Må- let är att hitta en lösning som är tillräckligt säker för att DOT/ITD ska tillåta mikrokontrollern att anslutas till deras nätverk och låta den hämta data från servern via Internet.

De relevanta säkerhetsmetoderna som dessa besitter undersöktes, testades och analyserades med avseende på motståndskraftighet mot attacker och lätthet att konfigurera och underhålla.

De valda metoderna var Internet Protocol Security (IPsec), Trans- port layer Security (TLS), Deep Packet Inspection (DPI). Medan säker- heten ansågs vara tillräcklig vare sig IPsec eller TLS användes, varierade lättheten att implementera och underhålla dem. På grund av risken för buggar i både protokoll och mjukvara är det nödvändigt att hålla sig uppdaterad om deras säkerhetsproblem.

(6)

List of abbreviations

AES Advanced Encryption Standard AH Authentication Header

CA Certificate Authority DES Data Encryption Standard DoS Denial of Service

DOT Department of Transportation DPI Deep Packet Inspection

ESP Encapsulation Security Protocol

HMAC Keyed-Hash Message Authentication Code IDS Intrusion Detection System

IETF Internet Engineering Task Force IKE Internet Key Exchange

ITD Idaho Transportation Department MitM Man-in-the-Middle

NAT Network Address Translation PPTP Point-to-Point Tunneling Protocol SA Security Association

SPI Security Parameter Index SSL Secure Socket Layer TLC Traffic Light Controller TLS Transport Layer Security

(7)

Introduction

1.1 Background

A project at the University of Idaho is aimed at adapting timings in traffic lights according to atmospheric and pavement conditions [41]. Depending on the weather, the yellow light is set to flash for a specific period of time. Icy roads lead to an increased yellow light time, giving motor vehicles a larger time frame to stop before other vehicles go, improving the safety of the intersection.

The project draws upon another one named the Clarus project, which uses environmental sensor stations to collect weather data. The data contains weather information such as temperature, humidity, atmospheric pressure etc. and is stored on a central server, referred to as the Clarus server. The stations are connected to a nationwide network that collects the data which then undergoes an advanced quality check to acquire reliable readings [31].

The analysis of the weather data is performed on microcontrollers, which communicate the changes to the traffic light controllers (TLC). New data is periodically downloaded from the Clarus server to a microcontroller for analysis, computing the preferred yellow timing and then sending the updated settings to the TLC.

Clarus

DOT/ITD control network

Internet

Figure 1.1. Overview

The control network is managed by the Idaho Transportation Department (ITD), a state agency related to the U.S. Department of Transportation (DOT), which primary purpose is to aid maintenance and development of the transportation systems in Idaho.

(11)

CHAPTER 1. INTRODUCTION

The network configuration that must be used is depicted in Figure 1.1. The DOT/ITD control network is currently an isolated network with "no" access from outside, due to obvious security concerns. The Clarus system is however accessible only via the Intranet. This makes it necessary to study mechanisms that allow limited communication from the Clarus server to the microcontroller in the intersections.

The network is fragile in the sense that the controllers accept any commands sent to them, no matter who the sender is. Since the network is so sensitive, DOT/ITD seeks to keep it as isolated as possible in order to prevent malicious users from manipulating it. The TLCs have up until now been connected to the traffic lights in completely isolated networks, but to be able to adapt the yellow timing to the weather, the networks need to be exposed to the Internet as shown in Figure 1.1.

ITD has agreed to allow this exposure only if they are convinced this project does not constitute a potential security risk.

Today the need for securing data and networks is a billion dollar industry [36].

There are various techniques used to secure connections over the Internet, some more robust than others - a few are endorsed while others are considered insecure.

History has shown that new technologies often have flaws, and as soon as a flaw is exposed the technology is useless until repaired. It is therefore important to constantly follow news concerning the defects affecting whichever technology used.

One of the techniques that are discussed in this report, and which is heavily utilized on the Internet to secure connections between peers, has again and again been shown to have weaknesses.

1.2 Problem statement

Placing a Rabbit microcontroller inside DOT/ITD control network and connecting it to the Internet is considered a significant security risk. A number of issues can be associated with this and they must all be addressed for ITD to allow the device into their network.

The following problems need to be mitigated. In Figure 1.2 a simple diagram can be seen with the corresponding areas of concern.

1. The weather data from the Clarus server could be modified or replaced by outdated readings on the way to the microcontroller.

2. The microcontroller itself could be compromised, letting an attacker directly manipulate its behaviour and control the network.

3. A Denial-of-Service (DoS) attack could prohibit the data from reaching its destination and stop the weather analysis.

4. A malfunction in the microcontroller could cause it to emit bad data or congest the network.

(12)

1.3. SCOPE

5. Other unauthorized access from the Internet to the devices in the control network.

The problem is to resolve these issues by inspecting the capabilities of the Juniper SRX210 services gateway and the Rabbit RCM4300 microcontroller’s and apply the appropriate countermeasures.

Internet

Clarus

ITD/DOT control network

Rabbit Juniper

3) 1)

2)

4) Attacker

5)

Device

Unauthorized access Internet connection Secured connection

Figure 1.2. Potential risks

1.3 Scope

Analysis and testing will only be done on the techniques that are applicable and feasible to the RabbitCore RCM4300 microcontroller and the Juniper SRX210 services gateway. Technologies that demand buying licenses or add-on equipment will not be studied.

Not in this thesis is how to secure the Clarus server from being compromised, neither is the subject on how to protect from physical attacks against the devices involved in the communication, shown as the dotted line in Figure 1.2, as it is deemed too complex to be discussed in this thesis.

1.4 Aims

Due to the sensitive nature of the application it is necessary to investigate a solution for securing a connection over the Internet between Clarus and Rabbit, restricted to the capabilities of the Rabbit RCM4300 microcontroller and the Juniper SRX210 services gateway. In Figure 1.2 this is the communication path between Clarus and the Rabbit, without the unwanted effects listed in Section sec:problem-statement.

(13)

Several solutions will be implemented and evaluated to determine suitability for weather data to be transfered, without exposing the network to risk of malicious intrusion. The study also aims to give a better understanding of the current state of technologies available for securing connections over the Internet.

By presenting the solution to ITD, convincing them that the chosen solution is sufficiently secure, we hope they will allow for the microcontroller to be added to the DOT/ITD network thus enabling the use of the safety application developed in [40, 41].

1.5 Methodology

The two devices in this thesis, the microcontroller and the security gateway, each have specific security features which need to be surveyed. The microcontroller ships with a software library containing connection management and security functionality. The security gateway has a vast array of configurable options to improve security and manage the network. By reading the documentation, the relevant security features of each device will be assessed. To better understand the relevant technologies, related literature as well as articles dealing with similar security problems will be studied. Also common attacks that could be used to compromise a control network or microcontroller will be researched so that they can be dealt with appropriately. An in-depth analysis of each defensive technique with respect to fea- sibility and effectiveness will help select the most prominent setup, which will then be implemented.

1.6 Equipment

The following section describes the key devices of the application. The microcontroller was selected for this thesis as it needed for the application in [40, 41]. The Juniper SRX210 was chosen by DOT/ITD to use in their network infrastructure.

1.6.1 Rabbit microcontroller

Figure 1.3. Rabbit RCM4300

The Rabbit RCM4300 microcontroller is developed and distributed by Digi In- ternational. It is programmed using the Dynamic C language, a subset of C with

(14)

1.6. EQUIPMENT

some extensions, most notably a proprietary multi-tasking technique. The microcontroller was chosen for this feature, which allows for fine grained control of thread execution, needed for the contingency management system developed in [40].

The model used in this project, the RCM4300, has a Rabbit 4000 microprocessor running at 58.96 MHz, a serial flash memory of 2 MB for software and a microSD card slot for data storage of up to 2 GB [46]. It uses the real-time operating system µC/OS-II implemented in Dynamic C, which application development is restricted to. Dynamic C is not fully compatible with ANSI-C, so in order to use a C library, it first has to be converted to Dynamic C [47]. These specifications poses restrictions that makes it difficult to extend the microcontroller’s security using third party libraries. Thus, only the libraries shipped with the Rabbit can be utilized with ease. For this thesis the Dynamic C version 10.70 is selected for development.

The microcontroller is marketed as a web server with capabilities of encrypting and securing transmission of data. It comes with libraries that include utilities for managing HTTP communication as well as technologies for securing data transfer.

1.6.2 Juniper security gateway

Figure 1.4. The Juniper SRX210

"Next Generation Firewall, IPsec VPN, Network Intrusion Preven- tion, best-in-class URL Filtering, Anti-Virus, Anti-Spam, and advanced Web 2.0 application identification for greater visibility, enforcement and control." [20]

The network industry has for a long time been dominated by Cisco. One competitor is Juniper Networks that started in 1998 and has since then grown strong, although still not as popular as Cisco.

The Juniper SRX210 is a security gateway aimed at small businesses, though it provides advanced security features such as VPN and antivirus protection. The SRX210 is placed in the low-end part of Juniper Networks SRX-series but the differences between the high-end and low-end devices lies mostly in hardware performance. Functionality-wise they are similar, running the operating system JunOS [19]. JunOS is built on FreeBSD and so provides a Unix-like environment for managing the gateway. There are two modes to switch between, operational and configuration, the former to execute commands and the latter for changing settings.

(15)

Each packet that the gateway receives is passed through a flow-based process before being forwarded to its destination. Packets are first analyzed by the Screen process, which protects against attacks attempting to overwhelm the network or probe it for information. Depending on from where packets are received and destined they are matched with Policies that determine how they should be treated, by for example permitting or rejecting them.

Among its security features there is support for IPsec VPN (Virtual Private Network), Network Intrusion Prevention and filtering capabilities that can be used to block unwanted connections and packets. IPsec VPN can be used both for site- to-site VPN, i.e. securing communication between two firewalls, and remote access VPN which secures the connection between a firewall and a remote client [21].

1.7 Roadmap of thesis

Introduction - The background of this thesis is described as well as the problem it seeks to solve. The chapter also shows what restrictions apply and the aims the thesis aspires to achieve. The methodology and the key devices used to solve the problem are also presented.

Theory - To better understand the problem and how the solutions work, this chapter describes the basics of how data is transmitted securely in networks.

Vulnerabilities - A number of typical attacks need to be mitigated, they are explained in this chapter.

Network Security Support - The possible solutions to protect against the attacks that were described in previous chapter are presented in the chapter.

Implementation - This chapter shows the setup used to implement the se- lected solutions.

Analysis - Advantages and shortcomings of the implemented solutions are discussed in this chapter together with alternative ones that were not explored.

Conclusion - Summarizes the work of this thesis and gives advice on how to the final implementation should be made.

(16)

Chapter 2

Theory

In this chapter we will describe the theory behind the methods used for securing the data transfer. Understanding the following concepts helps to comprehend the basics of secure communication and the challenges it involves.

2.1 Hash functions

A hash function creates compact representation of messages, called a hash digest.

A digest can be represented by for example a number or a string of characters, calculated by passing a message to a hash function. The function generates the hash by looking at each character in the message and, depending on the type of character and its position, calculates a value from it. The hash digest is important for a number of uses, not least in security applications. When two peers want to communicate, and be reasonably sure that the message one sends is intact, the message can be sent together with its hash digest. The receiver can then check that the digest, again calculated by the hash function, is the same as the digest that was sent with the message. If a message is modified, the hash function should return a digest that is different from the original one, even if it only differs by one character. Another use is that one can verify that other peers possess the same secret information by just asking for the information’s hash digest. Should the message be intercepted the secret information is not revealed.

It is not possible to directly calculate what the original message was from a digest since the same digest it could be generated by different types of messages.

However, by feeding a hash function with messages, it is possible to discover what type of messages evaluate to the original digest. Then the original message could be retrieved by figuring out which one of the those is likely to be the original.

Some hash functions can be exploited, but to make them more secure they should adhere to at least the following properties.

Pre-image resistance: It should be difficult to calculate what the original message was from just having the digest.

(17)

CHAPTER 2. THEORY

Second pre-image resistance: It should be difficult to create a message that is different from another message but which produces the same digest.

Collision resistance: The likelihood that two different messages have the same hash should be very small.

2.2 Public-key encryption

Information can be encrypted using so called public-key encryption. This encryption uses two different keys, one for encrypting the data and another one for decrypting it. The key that encrypts is called a public key and can be known by anyone without compromising the security. The key used for encryption is known as the private key and should only be known by the recipient. To encrypt the communication between two peers, each peer creates its own private and public key-pair and then publishes the public key to the other. Encrypting each message with the other’s public key, only the two parties can access the information being passed between them.

2.3 Key exchange

For two peers to begin encrypting their traffic they first have to negotiate a secret used for encrypting the messages. A common technique for doing this is using the Diffie-Hellman key exchange (DH).

The DH key exchange is done in the following manner. The peers agree on two numbers, one number g, known as the base and another number p which is a prime number. Each peer choses an integer a_x, calculates A_x = gâ^x mod p and sends A_x to the other. When receiving the other peer’s A_x, the secret s can be calculated, s = Aâ₂¹ mod p. The secret is now the same for the two peers even though their a’s are different as s = gâ¹^∗a² mod p.

2.4 Certificates and signing

Verifying peers identities over the Internet without previously sharing a secret can be done using certificates. When authenticating, a peer wants to verify the identity of another peer, like when a client connects to a server. The client can do this by asking the server to send the server’s certificate. When the certificate is received the client checks that the server is the one it claims to be by performing the following procedure. Calculate the certificate’s hash digest and compare it with the digest that is included in the certificate, if they are the same the server is who it says to be. This is secure only if a Certificate Authority (CA) is involved and has signed the certificate.

A CA is an entity that is trustworthy and whoever the CA trusts others can trust as well. If a server wants others to trust its identity, the server contacts a CA and sends the server’s certificate. The CA then makes a thorough investigation to

(18)

2.5. TCP/IP

verify that the server is who it claims to be and then signs the server’s certificate.

Signing is done by calculating the hash digest of the certificate, encrypting it with the CA’s private key and then adding it to the certificate before returning it to the server. The client keeps a list of CAs and their public keys which can be used to decrypt the encrypted hash digest that is in the certificate.

If a certificate is used on the Internet it should always be signed by a CA so that any user’s web browser can verify that the certificate and server is legitimate. For internal use there is no need to use a commercial CA, the certificates can be signed by a private CA or be self-signed and distributed manually. For the microcontroller, as well as the Juniper, a CA or a self-signed certificate can be created using OpenSSL.

The following command creates a self-signed certificate, i.e. a certificate that can only be verified by itself.

# openssl req -x509 -newkey rsa:2048 -sha1 -keyout private.pem -out cert.pem -days 365

It generates a 2048 bit public and private key and then asks for information about the issuer, e.g. country name, state/province, city, organization name and the unit name within the organization, the fully qualified domain name (FQDN) and email address. The FQDN is the address of the device that the certificate will be used for, it can be a DNS address or an IP address as in our case. When letting a known CA sign a certificate there is no need to distribute it to each user as their web browsers already have a list of CA’s public keys. With self-signed certificate each certificate must be manually added to the devices that connect to the server.

2.5 TCP/IP

Communication over the Internet is done using several layers of protocols. The protocols are referred to as the TCP/IP stack [22, 34] and consist of five layers, namely the physical-, link-, network-, transport- and application layer, associated with the standards in [3, 4]. When a message is sent from one computer to another, the message is passed through the layers, each layer encapsulating the message in information that lets it be directed to its destination. The layers will be only be briefly described and the grayed fields do not need to be explained to understand the concepts that will be introduced later.

The physical layer consists of the medium that the communication is handled by, often via cables or radio waves. Above this layer is the link layer that works within local network. When a message is sent within a local network it is encapsulated in an Ethernet frame which can be seen below in Figure 2.1.

Destination Source Type Data CRC

Preamble

Figure 2.1. Ethernet frame

(19)

CHAPTER 2. THEORY

The destination and source contains the MAC address of the receiver and the sender.

All network devices are identified by a MAC address which should be unique for every device connected to the network. The type tells what kind of packet is encapsulated in the data field so that it can be extracted correctly. CRC is a checksum over the frame that can be used to check if the frame was damaged during transmission and needs to be resent.

Encapsulated by the Ethernet frame, in the data field, is the network layer packets. Here resides protocols like IPv4, IPv6 and IPsec which are used to navigate the packets between networks. The IPv4 packet has the structure seen in Figure 2.2 below and is somewhat similar to the others mentioned.

Version Hlen Service Total length

Identification Flags Offset

TTL Protocol Checksum

Source address Destination address

Options Data

Figure 2.2. IPv4 packet

Again there are source and destination fields which this time contain IP addresses.

The next layer, stored in the data field, is the transport layer and the type of transportation protocol is specified in the protocol field.

Two common transportation protocols are the User Datagram Protocol (UDP) and the Transmission Control Protocol (TCP). UDP is used for data transmission where it is not crucial that every message reaches its destination, for example in when a message is outdated once a more recent one is available. TCP is for reliable connections, where messages should not be lost, and is achieved by sending an acknowledge back for each packet received. If the sender does not receive an acknowledgement then it will resend that packet until it does so or the connection is deemed broken. A TCP packet is depicted in Figure 2.3.

Using the sequence and acknowledgement number the peers can confirm that their messages have been delivered. When a packet is received the receiver sends back an acknowledgement packet (ACK) where the acknowledgement number is set to the total amount of data received from the start of the connection. The next packet

(20)

2.6. SECURE CONNECTIONS

Source port Destination port

Sequence number Acknowledgement number Data offset

Options + padding Data Reserved Flags

Checksum Urgent pointer

Window

Figure 2.3. TCP packet

that the sender sends has its sequence number set to that of the acknowledgement number that was in the ACK packet. In the data field is the actual data that is passed between the applications communicating at each end.

2.6 Secure connections

A secure connection can be defined in many ways and in this thesis we are mainly interested in the following three key principles that constitute the standard attributes of the definition of security.

Confidentiality - a message can only be understood by the two parties com- municating.

Authenticity - a receiver can verify the identification of a sender and a message can be verified to be from that sender.

Integrity - a message can not be changed during transit without it being detected.

2.6.1 Confidentiality

Sending confidential information such as passwords or classified documents requires either a private channel or encryption. As the Internet is a public channel, using encryption to secure private information is necessary. Today there are a number of encryption algorithms commonly used for this purpose.

Due to the constant increase in computer performance, encryption algorithms grows weaker over time, i.e. the encrypted information can be retrieved while it is still valuable. An example of this is the then popular Data Encryption Standard

(21)

CHAPTER 2. THEORY

(DES) encryption algorithm which is no longer considered secure to use [39]. DES was superseded by Triple DES (TDES), which is still considered feasible. Another common algorithm is Advanced Encryption Standard (AES), nowadays the recommended encryption algorithm to use [8]. All of them are available on the Juniper SRX210 while the Rabbit microcontroller only has support for AES. The strength of an algorithm is often determined by the length of the key it uses for encryption.

However, increasing the length of the key also increase the amount of computations needed to encrypt and decrypt a message.

2.6.2 Authenticity

Being able to identify a peer is crucial, else anyone can impersonate a valid source and trick others, either by sending them false information or make them reveal confidential information. Given the fact that the Internet is so open, being certain of someones identity can be difficult.

To authenticate a remote peer, a secret token is often used. Only authenticated peers should know the token and having the token proves an identity. Tokens can be simple passwords or more advanced variants such as digital certificates. Passwords are simpler to use but generally weaker and less secure than certificates.

When a client connects to a server that needs to be authenticated, the server sends the client a certificate signed by a CA that proves the servers identity. The client can verify the signature and thus ensuring the servers authenticity. Once the authenticity has been established, messages are hashed using Keyed-Hash Message Authentication Code (HMAC). HMAC is a technique that calculates a hash of the messages, together with the secret token the peers have negotiated, using a hash function such as MD5 and SHA-1. Every packet is authenticated by again calculating the hash of the packets content, together with the token, and then compare it to the hash attached to the packet. If the hash does not correspond to the one in the message it might be because the sender and receiver do not possess the same secret token.

2.6.3 Integrity

To protect a message from being modified between the sender and receiver, the message must have an integrity check. This is also achieved with a hash function.

As with authenticity the hash digest is computed using the content of the message, together with the secret token shared by the two parties. If the message is modified, the receiver will notice that the digest is not valid and can dispose of it.

Integrity does not only have to apply to a packets payload. For example, by including the packets source address in the hash, the source address can be protected from tampering, which could trick the receiver into believing the packet to be from a different source.

(22)

Chapter 3

Vulnerabilities

As stated in the problem specification there are a number of security issues that need to be mitigated. In this chapter common attacks methods are described and in the next chapter we will see how they can be mediated. The attacks relevant to the list of potential problems in Section 1.2 are described below.

3.1 Man-in-the-Middle

The Man-in-the-Middle attack (MitM) is a common problem needed to be taken care of when peers want to communicate securely. For the attack to be possible, the attacker has to place himself between the peers so that their messages must pass through him. This can be done for example by tricking the peers into thinking that the attacker’s address is the one of their partner’s. If the attacker is already in place before the peers have secured their channel, authenticating and encrypting the traffic becomes difficult.

When the peers begin communicating they first decide on the keys to use for encryption, in this example using public-key encryption. Ann and Bo wants to message each other and Eva is the attacker. Ann sends her public key to Bo but Eva intercepts it on the way. Instead of sending Ann’s key to Bo, Eva sends her own, which Bo thinks is Ann’s key. Eva does the same switch when Bo sends his public to Ann. Eva has now taken over the communication and every message Ann sends, Eva can just decrypt, read and/or modify, encrypt it with the Bo’s public key and send it to Bo, without neither Ann or Bo being able to notice. The attack is very powerful since the attacker gains complete control of the communication and is also difficult to detect.

3.2 Denial-of-Service

A common way to block connections to a host is to use a Denial-of-Service attack.

Since a server can only handle a limited number of clients at any given time, having too many of them connect at once will render the server unable to serve some, if not

(23)

CHAPTER 3. VULNERABILITIES

all, clients. The attack can be done in some different fashions. An attacker could use only one computer to create a large amount of fake connections, tricking the server that it has to serve more clients than there really are. It could also be done if the attacker manipulated a large number of computers into connecting to the server at the same time, known as a Distributed Denial-of-Service attack (DDoS).

The manipulation can be achieved either by hijacking the clients with a virus or mislead a large amount of normal users to connect to the server. Defending against the attack can be almost impossible as it is difficult to determine if a user is legit or not.

3.3 Replay attacks

Even though authenticated and encrypted messages passed between two peers are unreadable, an attacker could still use them in an attack. If the attacker is able to eavesdrop on the communication he can store the messages for later. Since the messages are legit, they can be sent to the peers who will accept them even though they are not from who they think they are. In the case that messages are encrypted it is difficult for the attacker to figure out what each message contains, but with clever use they could still be efficient for manipulation. One example of this is in the case of a bank transaction where an attacker can eavesdrop on a transaction, save the messages, and then replay them back to the bank’s server for the transaction to be repeated.

3.4 Remote code execution

Applications that handle input sometimes fail to do it in a secure way. If an in- putted block of data is larger than expected and the application tries to store it in memory anyway, the following could happen. The application overwrites data stored in memory that was not meant to be overwritten, causing the application to crash, either by not being able to handle the new data in that memory location, or the overwritten data was required for the application to function. Having the application crash could be bad enough but if it instead tries to execute the unexpected data, the application could be manipulated into performing malicious operations.

An attacker could design a message that the application can’t handle correctly and which includes a series of operations the attacker wants to execute.

3.5 Physical attacks

Protecting a device that an attacker has physical access to is considered very difficult. The attacker can easily dump the device’s memory in order to gain access to passwords and other critical information stored on it. For devices like the microcontroller in this thesis, the attacker could also replace the current application with his own version to get complete control over the device. A recent example of this is

(24)

3.5. PHYSICAL ATTACKS

described in [42] where an Indian voting machine was proved to be an easy target for manipulation.

(25)

(26)

Chapter 4

Network Security Support

Below are the descriptions of network security mechanisms that are relevant to our application.

4.1 Transport Layer Security

Transport Layer Security (TLS) is used frequently for communications over the Internet. It secures connections between peers by using certificates for authentication and key exchange. When a client connects to a server, that the client wishes establish a secure connection with, the following exchange is made.

1. The client sends a ClientHello message with information such as its TLS version, the cipher suits it supports and a randomly generated number.

2. The server responds with a ServerHello message. It contains the selected TLS version, cipher suite and its own randomly generated number.

3. The next message contains the server’s certificate.

a) The client checks that it is valid by decrypting the certificates signature with the corresponding CA’s public key. If the decrypted signature, which is a hash digest of the certificate calculated by the CA, corresponds to the digest of the certificate calculated by the client then the certificate is valid.

b) The address of the server is also in the certificate and must be verified to be the same as the address being connected to.

c) Optionally the server requests the client’s certificate if the client needs to be authorized.

d) The certificate also contains the servers public key which the client uses to encrypt the pre-master key that was generated using the two randomly generated numbers.

(27)

CHAPTER 4. NETWORK SECURITY SUPPORT

4. The client tells the server that from now on it is encrypting its communication and then a ClientFinish message.

5. The server responds that it too will start encryption and then sends a ServerFin- ish message.

6. If everything went well the connection is now secured, otherwise the handshake is terminated.

4.1.1 History

The specification for the predecessor to TLS, Secure Socket Layer (SSL), was created by Netscape in the mid-nineties. Since then it has been updated several times to improve security and repair security holes, but old versions are still around. For example, SSL 2.0 is no longer considered secure to use [6] but is still supported by 24.7% of the web servers surveyed by [35]. Version 3.0 of SSL is also advised against [5, 30] since it uses the MD5 hash function when deriving the pre-master key, which is a small security concern as MD5 is not sufficiently collision resistant [27]. Another popular hash algorithm is SHA-1 which is stronger although it is recommended that they both are replaced by SHA-2 [5]. SSL 3.0 was superseded by TLS 1.0, specified by Internet Engineering Task Force (IETF) in RFC2246 [9], and addresses some issues such as the downgrade attack where peers are tricked by an attacker into using weak algorithms. Today TLS is supported by most popular web browsers and there have been two updates released since its first version, 1.1 and 1.2, slightly improving security, but not yet widely adopted. Even though TLS now is more common than SSL, the terms SSL and TLS are used interchangeably when referring to TLS.

4.1.2 Known attacks and preventions

There are many ways to defeat TLS, e.g. it can be done by exploiting flaws in the protocol itself, specific implementations of it, or taking advantage of human behaviour.

Two recent attacks on the protocol are BEAST [12] and CRIME [38]. They are used for recovering information in encrypted traffic such as session cookies, which can be used to impersonate authenticated users. However, this is not an issue for our purpose, we are only concerned with data integrity and authenticating the server, session cookies are of no concern.

Another type of downgrade attack is to make a client redirect from the HTTPS portal to the HTTP one if such exist. This way the connection is completely exposed and the communication can be manipulated however the Man-in-the-Middle attacker wants. Web browsers try to make these type of attacks difficult by alerting the user if the connection doesn’t use TLS. The attack works only if the following two conditions are true. The user is not wary of the web browsers warning, and the server the user is connecting to serves both HTTP and HTTPS. MitM attacks can

(28)

4.2. IP SECURITY

also replace the server’s certificate with a faked one and hope that the client still accepts it, despite the warning signs normally shown. For our objective this is not a problem as we connect to a fixed IP address and do not allow redirects. If the microcontroller receives a certificate that is not valid, the connection is terminated immediately.

As an example to show that specific implementations can have security flaws, let’s look at OpenSSL. It is an open source implementation of SSL/TLS, developed by volunteers. Because OpenSSL is a community effort it is also very transparent. On their website¹ a list of discovered security bugs can be seen. Although many of the bugs are not severe it shows that they are not rare and there is always a risk that graver flaws are found, which highlights the importance of closely following news concerning security technology like this. OpenSSL is a part of the Rabbit Embed- ded Security Pack but only for generating certificates on a workstation. The TLS library included in the Dynamic C distribution is, however, completely proprietary and not based on OpenSSL [45].

4.2 IP security

The Juniper SRX210 that was selected for use by DOT/ITD has support for the IP security protocol (IPsec), which can be used to create secure connections between two hosts or for Virtual Private Networks (VPN). VPN is often used by enterprises to secure communication between branches or for employees accessing the intranet from a remote location. The usage of VPNs has also greatly improved the security for private users. When the technology was first introduced, VPNs were only available for enterprises through Internet Service Providers, but today numerous services are available for private use. There are several ways to implement a VPN and the most popular uses TLS or IPsec.

The IPsec protocol is defined in the RFC2401 [25] and is a collection of protocols, two used for transportation and one for key exchange. The two types of packet protocols, Authentication Header (AH) and Encapsulation Security Protocol (ESP), have specific purposes and can be used separately or together. For negotiating security parameters and encryption keys the Internet Key Exchange (IKE) is utilized.

4.2.1 Transport mode and tunnel Mode

IPsec packets can be transported using either transport mode or tunnel mode.

Transport mode is aimed at host-to-host communication and is not used for VPNs, only to secure communication between two specific hosts. Tunnel mode creates a tunnel between two endpoints, e.g. two routers. This is done by encapsulating the whole ESP or AH packet into a new IP packet with the source and destination address of the two endpoints. When the tunneled packet arrives at the endpoint, the inner packet is extracted and can be forwarded to the correct destination.

1http://www.openssl.org

(29)

4.2.2 Protocols

As mentioned, IPsec consists of several protocols which can be active or inactive depending on preference. The IPsec protocol was built with modularity in mind so that older protocols can be replaced with newer ones if necessary.

Authentication Header The Authentication Header protocol provides authenticity and integrity but not confidentiality. The way it does this is by calculating a hash digest of almost the entire IP packet, protecting it from being manipulated.

It does however have a drawback, changing the destination IP address will inval- idate the hash. This occurs when the packet passes a router that uses Network Address Translation (NAT). Only if the packet can reach its destination without passing through an intermediate router can AH be utilized, no matter if the transport mode or the tunnel mode is employed. To address this problem, NAT-T needs to be supported. When two VPN endpoints communicate, and there is a device that uses NAT in between them, both endpoints must support NAT-T. NAT-T encapsulates the packet and adds a UDP header so that it can be transported without invalidating the hash.

Encapsulation Security Protocol The Encapsulation Security Protocol can be used for authenticity, integrity and also confidentiality. Instead of hashing the IP packet, ESP encapsulates the TCP header and payload, encrypts it and then puts it in the IP packet payload together with its hash. ESP makes AH seem somewhat redundant since it provides the same services and more, while not having any issues with NAT. If there is no desire to encrypt the data then encryption can be turned off. It is also possible to deactivate authentication, but this can expose the communication to more attacks [7, 32]. As we will be using ESP instead of AH, we will explain its structure in detail, it can be seen in Figure 4.1 and depicts what it looks like in tunnel mode, when encapsulated in an IPv4 packet for transportation. The gray areas show what parts of the packets are encrypted, while the area surrounded with dashed lines are authenticated. The SPI will be explained shortly in the next subsection. The sequence number works as a protection against replay attacks by dropping packets with a sequence number that has already been seen. Padding is used to improve encryption since the real length of the payload can not be deduced. Lastly, the authentication data is the hash that protects the integrity and provides authentication for the information inside the dashed lines.

4.2.3 Internet Key Exchange

IKE is derived from the protocols Oakley and SKEME, using the Internet Secu- rity Association and Key Management Protocol (ISAKMP) framework as base.

ISAKMP defines the mechanics used to implement new key exchange protocols, IKE being most known. The framework allows for different encryption algorithms

(30)

4.2. IP SECURITY

Version Hlen Service Total length

Identification Flags Offset

TTL Protocol=ESP Checksum

Source address Destination address

SPI Sequence number

TCP Header + payload

Padding

Padding len Next=IP Authentication data

IP Header

Figure 4.1. ESP packet

and authentication methods and is not bound to be used with IPsec, it can serve as a framework even for other protocols like TLS.

IKE’s purpose is to establish so called Security Associations (SA). SAs are used for keeping track of what each IPsec connection uses as encryption protocol and encryption key. Each IPsec packet contains a Security Parameter Index (SPI) to associate with the correct SA.

During a two phase handshake one SA per phase is created. In the first phase the peers are authenticated and a Diffie-Hellman key exchange is made to establish a secure channel. In the second phase, the secure channel is used to negotiate what encryption and hash algorithms to use. When the second phase is complete the traffic is secured and communication can begin.

There are two different modes that IKE can use, main mode and aggressive mode. In main mode the first SA is negotiated using 6 packets, instead of 3 as with aggressive mode. The main mode protects the identity of the peers, such as the IP address, DNS name or email address. It does this by sending the information only once Diffi-Hellman key exchange has been made.

The first specification IKE, version 1, was suggested in RFC 2409 [17] but had some flaws [48]. Since then it has been been updated with more clarifications until finally a version 2 of the protocol was specified in RFC 4306 [23]. IKEv2 provides some advantages to the previous version, for example more resilience to DoS attacks

(31)

and it is easier to implement since some of the complexity in the first version is removed, such as aggressive mode.

4.2.4 Known attacks and preventions

Aggressive mode should not be set when a pre-shared key (PSK) is used for authentication instead of a certificate. This is because the hash digest of the PSK is sent during the handshake and can be sniffed. With the PSK hash the password can be recovered using a so called dictionary attack. The attacker can figure out the PSK by generating a list of possible passwords, calculate the hash for each of the them and if the hash matches the hash of the PSK, then that could be the key. The most important reason aggressive mode exists is because it allows for clients that do not have a static IP address to connect using another identifier than the IP address.

To exchange keys with Diffie-Hellman the length of the key needs to be large enough so that an adversary can not crack it too quickly. Larger keys do however demand more computing power and will affect the connection speed. The shortest key length is 768 bits and is called group 1. The longest group available on the Juniper is group 14 with a length of 2048 bits which we recommend to maximize security for our project since speed is not an issue.

IPsec can be configured with many type of cipher suits. Even though DES-CBC is available it is not considered secure and should not be used. Again, the stronger the encryption the slower the connection speed. In our case, as we are not sending large amounts of data, it is best to chose the strongest one, AES-256-CBC.

When IPsec is set up between two routers, the traffic is secured between the two only, outside them there is no secure communication. If an attacker has access to the network before the router then the traffic can still be manipulated. In Section 4.2.4 the dashed line shows where data is secured while the continuous lines shows where it is not.

Clarus network

DOT/ITD network Internet

Clarus Router Router Rabbit

Figure 4.2. Traffic is only secured in the dashed line.

As with TLS, the implementation itself could have security issues due to bugs.

The Juniper router does also need be kept updated as vulnerabilities are sometimes discovered. A recent example was a bug in the TCP packet processing that caused the router to crash [10].

(32)

4.3. DEEP PACKET INSPECTION

4.3 Deep Packet Inspection

The second item in the list in Section 1.2 states the problem of the microcontroller being compromised by an attacker, which might be possible using remote code execution, explained in Section 3.4. To make the attack more complicated to perform, we want to filter out packets which contain bytes not used by our weather data.

Remote code execution attacks rely on tricking the victim into executing the data that is delivered by the packets. The data has to be tailored so that the victim in- terprets the data as the attacker wants. If the attacker can not send just any data, only the type we allow, tailoring malicious data will be more difficult. Filtering can be achieved using Deep Packet Inspection (DPI).

Firewalls are generally concerned with the IP and transportation layer. One of the primary purposes is to block IP addresses that are not authorized and only allow connections that first originate from inside the network, in order to keep out unwanted peers. The need for even more fine grained management of packets is dealt with using DPI. By inspecting the content of the application layer, the firewall can guard against a number of security issues. For example, the firewall could block packets that form an executable file, which sometimes can be a security concern.

For more detailed filtering the firewall can access databases with virus signatures that the packet content can be compared with.

(33)

(34)

Chapter 5

Implementation

In this chapter we present the setup that was created in our laboratory in order to test the implementation. The solutions that we selected are then described and argued.

5.1 Setup

To imitate the environment that the system will be used in, the following setup has been created. The Clarus server is implemented using a local mirror site, called Local Clarus Server (LCS). It serves plain text files with weather data in CSV format, accessible via a web link and is connected to a switch. The switch directly connects to the Juniper SRX210 and acts like the connection over the Internet.

Inside the Juniper network another switch is attached, creating two subnets, one for the TLCs and one for the microcontroller. Below, in Figure 5.1, an overview of this setup is shown, followed by Figure 5.2 and Figure 5.3 depicting the hardware that was used.

Using Wireshark¹ to see what packets are sent over the network it is easy to verify that a connection is established and secured.

First IPsec was configured and tested and then the same was done for TLS.

5.2 Juniper SRX210

At the heart of this project is the Juniper. The choice of the Juniper was dictated by the specification of the project sponsor. In this section we show how it was configured to secure the connection between the LCS and the Rabbit. DPI was not activated on the Juniper as it demanded a license to be used.

1http://en.wikipedia.org/wiki/Wireshark

(35)

CHAPTER 5. IMPLEMENTATION

Microcontroller

Switch Juniper

Internet

Router LCS

Traffic Light Controller

Figure 5.1. Overview of the setup

Figure 5.2. Setup in the lab (TLC not shown)

5.2.1 IPsec

Because we only have access to one router with IPsec capabilities, and two are needed to create a tunnel, a virtual machine (VM) was used. The VM runs the operating system pfSense² which is an open source firewall and router. As the VM runs on the same machine as the LCS, the connection from the web server first

2http://www.pfsense.org

(36)

5.2. JUNIPER SRX210

Figure 5.3. From the bottom: Juniper SRX210, Linksys BEFSR41v2, TP-Link TL-R860, Rabbit RCM4300

goes in to the VM’s LAN interface and out through it’s WAN interface, which is the Ethernet cable connected to the switch. The configuration is depicted in Figure 5.4.

It is easy to configure IPsec with pfSense and the procedure will not be described here. The settings in pfSense need to exactly match the ones on the Juniper device in order for the communication to work.

Computer pfSense LCS (Virtual machine) Rest of lab WAN

setup

Figure 5.4. Virtual machine integration

To create an IPsec tunnel on the Juniper SRX210 there are a number of options that must be configured. For the first phase of the handshake, IKE needs to specify a so-called proposal that decides what Diffie-Hellman (DH) group to use, encryption algorithm, authentication algorithm, authentication method and the lifetime of the first SA. These settings are only used for securing the second phase of the handshake.

(37)

The DH group option allows for keys with bit-length between 768 and 2048. Because the length 768 is deprecated and not recommended, at least DH group 2 with bit- length 1024 should be picked. DH group 14 is however the largest one providing maximum security and is selected given our tolerance to overhead. The strongest authentication algorithm available is SHA-256 and for encryption we choose AES- 256-CBC. The authentication method is set to use RSA signature, which is safer than using a PSK. The lifetime is the duration until the complete handshake must be remade. Since the amount of traffic that will be tunneled is not large it does not matter if this is a low value.

Having set the options on the Juniper, the configuration summary is shown below.

proposal ike_proposal {

authentication-method rsa-signatures;

dh-group group14;

authentication-algorithm sha-256;

encryption-algorithm aes-256-cbc;

lifetime-seconds 3600;

}

To specify which connection uses what proposal, a policy needs to be configured.

A policy specifies what proposals that are accepted, the type of mode, main or aggressive and the PSK or certificate depending on the authentication method.

The resulting configuration follows.

policy ike_policy { mode main;

proposals ike_proposal;

certificate {

local-certificate my_certificate;

peer-certificate-type x509-signature;

} }

Finally we specify for which connections the IKE policy should be applied. For better resilience to DoS attacks version 2 of IKE is used, i.e.,

gateway ike_gateway { ike-policy ike_policy;

address 192.168.1.2;

external-interface ge-0/0/0.0;

version v2-only }

Then the specification for IPsec has to be created. Again specify authentication algorithm, encryption-algorithm, lifetime and protocol. This time the encryption

(38)

5.2. JUNIPER SRX210

and authentication algorithm is what is actually used for the encryption of the data.

As the information is not confidential the encryption algorithm is not specified.

proposal ipsec_proposal { protocol esp;

authentication-algorithm hmac-sha-256-128;

lifetime-seconds 3600;

}

Perfect forward secrecy is used to renegotiate keys after a certain time so that the same key is not used long enough to be cracked.

policy ipsec_pol {

perfect-forward-secrecy { keys group14;

}

proposals ipsec_proposal;

}

Link the IKE configuration with the IPsec one and also specify when the tunnel should be created.

vpn ipsec_vpn { ike {

gateway ike_gw;

ipsec-policy ipsec_pol;

}

establish-tunnels immediately;

}

Then we have to set the policies that dictate how traffic is handled depending on its attributes. We need to set up two policies, one for traffic coming into the network and one for traffic going out. The trust zone is our local network where the TLCs and the microcontroller are connected and the untrust zone is for all connections coming from the Internet into the local area network. The following settings specify how to handle traffic coming from the untrusted zone to the trusted one. A similar policy is created for the traffic going out from the trusted zone to the untrusted.

from-zone untrust to-zone trust { policy vpn-utr-tr {

match {

source-address clarus-net;

destination-address rabbit-net;

(39)

...

} then {

permit { tunnel {

ipsec-vpn ipsec_vpn;

pair-policy vpn-tr-utr;

} ...

To verify that the setup is working, Wireshark is used to collect and view the packets sent when the configuration loaded. The protocol of the first 9 packets are ISAKMP, 6 for phase 1 and 3 for phase 2. After this is done the next packets’

protocol is ESP.

5.3 Rabbit microcontroller

On the Rabbit microncontroller we implemented two solutions which are described in this section, TLS and DPI.

5.3.1 TLS

Configuring the microcontroller to use TLS is simple. First we specify that AES encryption is used instead of the RC4 cipher, which is less complex but weaker.

Then we import the TLS library in the source file, this has to be done before the import of the client HTTP library. With another import statement we can upload a X.509 certificate to the Rabbit. Lastly we create a global struct to hold the certificate information. The code in Listing 5.1 shows how this is done.

Listing 5.1. TLS import and definitions

#d e f i n e SSL_USE_AES

#use " ssl_sock . l i b "

#use " h t t p _ c l i e n t . l i b "

#ximport " s e r v e r . c r t " ca_pem SSL_Cert_t t r u s t e d ;

The TLS library performs basic verification of the certificate, to see that is has been signed correctly, but a callback handler can be used to perform extra checks. In Listing 5.2 we compare the hostname of the certificate with that of the server to make sure that we are connected to the same server that the certificate was created for.

(40)

5.3. RABBIT MICROCONTROLLER

Listing 5.2. Certificate callback handler

i n t t l s _ c a l l b a c k ( ssl_Socket f a r ∗ stat e , int trusted , s t r u c t x 5 0 9 _ c e r t i f i c a t e f a r ∗ cert , httpc_Socket f a r ∗ s )

{

i f( strcmp ( cert −>s u b j e c t . cn , s−>hostname ) ) {

p r i n t f ( " C e r t i f i c a t e i n f o mismatch . \ n " ) ; return 1 ;

}

return 0 ; }

The initialization of the TLS is done by loading the CA’s certificate and configuring the TLS settings to require a certificate from the server. This is shown in Listing 5.3.

Listing 5.3. TLS initialization void i n i t _ t l s ( )

{

i n t rc ;

memset(& trusted , 0 , sizeof ( t r u s t e d ) ) ;

rc = SSL_new_cert(& trusted , ca_pem , SSL_DCERT_XIM, 0 ) ; i f( rc )

{

p r i n t f ( " Fa i l e d to parse c e r t i f i c a t e \n " ) ; return;

}httpc_set_tls (SSL_F_REQUIRE_CERT, NULL, &trusted , t l s _ c a l l b a c k ) ; memset(&ssl_sock , 0 , sizeof ( ssl_sock ) ) ;

sock_init_or_exit ( 1 ) ; }

5.3.2 Deep Packet Inspection

Because the DPI on the Juniper was not customizable enough for us to be useful, we created our own implementation on the Rabbit instead. The library distribution includes an option to customize the handling of packets that the microcontroller receives and sends. By inspecting each packet before it is processed by our application we can make sure that it does not contains anything unexpected. As our application is only expecting certain characters, we can make sure that only packets containing that set of characters are forwarded to it.

There are a couple of ways that this can be achieved. The library allows for callback function to be invoked by macros, useful for customizing the handling of packets. The following two macros are helpful, CUSTOM_IP4_HANDLER and TCP_DATAHANDLER. The first one allows us to manage the data of the whole IPv4 packet before it is processed by our application, while the second one gives access to the data segment of the TCP packet.

(41)

For simplicity the TCP_DATAHANDLER is used and the function below in Listing 5.4 handles the packets. It reads the data in the payload by first copying it from the extended memory into a local buffer and then checks for each character that it is not a control sequence, except backspaces and tabs. If a control sequence is found, the connection is closed and the packet discarded.

The event variable describes what type of event is happening, in this case data is being received. The void pointer s points to the tcp_Socket structure that controls the connection. The ll_Gather pointer g points to a structure that holds the mem- ory addresses of the packets header and payload. We are interested in the payload which starts at the address g->data2 and which size is g->len2 .

Listing 5.4. Packet handler

i n t ∗ tcp_handler ( int event , void ∗s , ll_Gather ∗ g , void ∗ i n f o ) {

i n t i , j , l e n ; char d [ 1 2 8 ] ;

i f( event == TCP_DH_INd) {

f o r( i = 0 ; i < g−>len2 ; i += 128) { i f( g−>len2 − i < 128 ) {

l e n = g−>len2 − i ; } else {

l e n = 128;

}xmem2root (d , g−>d2 + i , l e n ) ; f o r( j = 0 ; j < l e n ; j++) {

i f( ! isalnum ( d [ j ] ) && ! i s s p a c e ( d [ j ] ) &&

( d [ j ] < 44 | | d [ j ] > 47) && d [ j ] != 95) { tcp_abort ( ( tcp_Socket ∗) s ) ;

} } } }

return 0 ; }

(42)

Chapter 6

Analysis

In this chapter we discuss the solutions that were selected, looking at their strengths and weaknesses. We also outline some technologies that could be used to further improve security.

6.1 IPsec

The IPsec protocol has been around since 1998 [25] and many improvements have been made since then, e.g. RFC4301, RFC5996 and RFC6071. IPsec was developed alongside IPv6 so the technique is standardized and is still being improved. Most of the authentication and encryption algorithms available are strong, such as SHA-256 and AES-256-CBC, and when they become obsolete the protocol can adopt newer and stronger ones. However, there are still concerns that need to be noted.

IPsec has received critique from several sources, mainly due to its complexity [11, 13, 33]. It can also be argued that the existence of AH is not motivated now that ESP can do what AH does while not having difficulties with NAT. As mentioned in [13], the existence of redundant features is a typical issue that arises when a committee is involved, as compromises have to be made to keep all parties satisfied.

On a side note, NAT-T was specified in 2005 [18, 26] and has had a long time to be adopted by router manufacturers so it is likely to be supported by modern routers.

The complexity problem is apparent looking at the number of options needed to be configured and is due to the modular philosophy of IPsec. To improve security it would have been better to remove some options and force authentication to always be activated, then an attack such as [7], would not be possible. Among the encryption algorithms, DES-CBC is available even though it has been proven to be insecure [39] and the same goes for having DH group 1 selectable. There is also no room for flexibility when negotiating settings between two IPsec devices. When configuring a tunnel between two devices, the settings must match exactly, even the SA lifetime, otherwise no connection is established.

When it comes to the authentication methods, using pre-shared-key (PSK) as authentication is easy, but should at most be utilized for testing purposes as there

A Survey on Security Considerations forMicrocontrollers in Traffic Light Networks

A Survey on Security Considerations for Microcontrollers in Traffic Light Networks

Johan Cronsioe

A Survey on Security Considerations for Microcontrollers in Traffic Light Networks

Abstract

Referat

En Studie om Säkerhetsbeaktanden för Mikrokontroller i Trafikljusnätverk

List of abbreviations

Contents

Chapter 1

Introduction

1.1 Background

1.2 Problem statement

1.3 Scope

1.4 Aims

1.5 Methodology

1.6 Equipment

1.7 Roadmap of thesis

Chapter 2

Theory

2.1 Hash functions

2.2 Public-key encryption

2.3 Key exchange

2.4 Certificates and signing

2.5 TCP/IP

2.6 Secure connections

Chapter 3

Vulnerabilities

3.1 Man-in-the-Middle

3.2 Denial-of-Service

3.3 Replay attacks

3.4 Remote code execution

3.5 Physical attacks

Chapter 4

Network Security Support

4.1 Transport Layer Security

4.2 IP security

4.3 Deep Packet Inspection

Chapter 5

Implementation

5.1 Setup

5.2 Juniper SRX210

5.3 Rabbit microcontroller

Chapter 6

Analysis

6.1 IPsec