1194 research outputs found
Sort by
Segment Routing Service Programming
Get PDFIn the last few years, the IT network domain has changed fundamentally. New approaches and technologies were introduced, which has changed and is changing the future of this area radically. The results are modern and dynamic networks that close the gap between networks, applications, and end-users. It permits creating applications that work closely with the underlying network and create a network that fulfills customer needs entirely. Network services like firewall systems or intrusion detection/prevention systems have become indispensable and are firmly anchored in computer networks. Nowadays, these services are not to assume away yet have also a massive disadvantage: they are consumed in a static manner. Service Programming is one of the outcomes in future networks and solves the problem of static service consumption. It allows configuring the network dynamically so that network services can process customer traffic according to their necessities. Following network services can be placed universally in the network - the service programming application will find the best services according to the traffic characteristics. Hence, networks with integrated service programming become more intelligent, economic and are prepared for future needs.
This thesis is a follow-up thesis from the Service Chaining Path Calculation thesis written in the autumn term of 2020, which introduced a way to calculate service chains in a Segment Routing network. This bachelor thesis aimed to find a solution that can help program so-called steering policies in the network to steer the traffic according to the needs of the customer networks over the most suitable services. In order to achieve this goal, the network protocol Segment Routing with the IPv6 data plane (SRv6) was used. The goal was to deliver an application that can calculate and program the best suitable path according to specified parameters from the customer. The application should react dynamically to changes in the connected network and deliver consistently the best policy that fits the altered topology. As a consequence, the user can always rely on the data on which he is working. Hence, the application always had to know the present network topology and has to be informed about network changes. An external system is used to get the actual topology data; the system aggregates and processes all the topology information, which can be used in so-called Segment Routing applications.
During the bachelor thesis, a complete Service Programming application could be developed. The application is developed entirely in a cloud-native way in order to be highly scalable and available. The application consists of different services, which communicate with each other over a dedicated messaging system. A polling service handles all the update messages from the topology and informs the backend service automatically about changes. The backend service uses the topology data to perform path calculations, deploy policies to the underlying network, and deliver the topology data so that the frontend can easily visualize the network and paths. The frontend was developed in collaboration with the Institute for Networked Solutions and provides the customer an easy-to-use way to create and manage policies over the backend
NovaMobile BA
Get PDFProblem:
Die Novasina AG ist eine KMU mit Sitz in Lachen SZ, welche sich auf Messtechnik und Sensorik spezialisiert hat. Ihr primäres Expertisengebiet sind Feuchtigkeits- und Temperatursensoren, die vor allem in Lebensmittel- und Medizintechnik zum Einsatz kommen. Da diese Sensoren nicht nur stationär installiert werden, sondern zum Beispiel für Audits auch mobil einsetzbar sein müssen, besteht Bedarf nach einem handlichen Gerät, das mit den Sensoren kompatibel ist und deren Messresultate auslesen, anzeigen sowie speichern kann. Ein solches Gerät, auf proprietärer Hardware basierend, existiert mit dem Novasina ClimMate-Gerät bereits. Die Novasina AG wünscht sich jedoch aus Marketing- und Kostengründen eine Mobile-App, welche dieselbe Funktionalität für handelsübliche Smartphones anbietet.
Ziel:
Ziel dieser Arbeit ist die Erstellung einer solchen App, die unter Android betriebsfähig ist. Kernpunkte sind dabei:
• Anschliessen eines Novasina-Sensors mit USB-Kabel
• Auslesen der gemessenen Klimadaten
• Speichern dieser Daten auf dem Smartphone
• Tabellarisches und grafisches Darstellen der Messwerte
• Klimarechner für die Berechnung fiktiver Klimawerte
Wesentliche Ergebnisse:
Finales Resultat der Arbeit ist eine Android-Applikation, die das Xamarin-C#-Framework nutzt und auf handelsüblichen Smartphones (Android-Version 8.0 Oreo oder neuer) einsetzbar ist. Sie ermöglicht es, die nSens-Fühler der Novasina AG zur Messung von Feuchtigkeit und Temperatur mittels USB-Kabel an das Smartphone anzuschliessen und deren Messdaten auszulesen, Momentaufnahmen oder längere Logs abzuspeichern sowie zu exportieren. Darüber hinaus bietet sie einen Klimarechner an
Hydranten Finder App
Get PDFIn dieser Arbeit zeigen die Autoren auf, wie eine Problemstellung aus der Praxis nach einem nutzerzentrierten Vorgehen effektiv evaluiert und ein vielversprechender Lösungsansatz mit Lean UX validiert werden kann. Durch dieses Vorgehen stand dem Auftraggeber bereits zum Schluss dieser Arbeit ein validiertes, lauffähiges Produkt «MVP» als Mobile App zur Verfügung.
Konkret wurde mit umfangreichen Contextual Inquiries untersucht, ob es tatsächlich Probleme bei der Sicherstellung der Wasserversorgung bei einem Löscheinsatz der Feuerwehr gibt und wie häufig diese vorkommen. Nach einer Evaluation möglicher Lösungsansätze basierend auf den Erkenntnissen aus Recherche und Beobachtung wurde in einem Lean UX Vorgehen der Lösungsansatz einer Mobilen App ausgearbeitet und mit Nutzern im Sinne dieses Vorgehensmodells validiert.
Die Autoren empfehlen das MVP entsprechend den Erkenntnissen aus den Tests zu optimieren und darauf eine Pilot-Version einer Gruppe von Feuerwehrleuten zur Nutzung bei realen Einsätzen zur Verfügung zu stellen. Im Anschluss kann die App um die weiteren, in dieser Arbeit definierten Features erweitert werden
Kommunikations- und Planungslösung mit JHipster
No full textIn der heutigen Zeit besteht ein Überangebot an verschiedenen Kommunikationsplattformen. Auf dem durchschnittlichen Mobiltelefon finden sich zahlreiche Chat-Apps, die unterschiedlich häufig verwendet werden. Wenn verschiedene Kommunikationskanäle benutzt werden, können Nachrichten allerdings leicht verloren gehen, oder werden erst spät und inkonsistent beantwortet. Daher soll eine Plattform entwickelt werden, die Kommunikationskanäle bündelt und zentral verwaltet.
Zu Beginn der Arbeit wurde der Markt bestehender Omnichannel-Plattformen analysiert und somit der Entwicklungsbedarf des Produkts ermittelt. Zudem wurden existierende Schnittstellen analysiert, um die Machbarkeit der Integration verschiedener gängiger Kanäle zu ermitteln. Bereits zum Projektstart wurde festgelegt, die Eignung des Rapid Application Development Frameworks JHipster zu evaluieren und dieses dann ggfs. zu verwenden. Des Weiteren haben wir ein User-Interface Konzept ausgearbeitet, welches bereits in einer frühen Phase des Projekts eine Vorschau auf die Applikation ermöglichte.
Im Rahmen der Bachelorarbeit ist ein Architekturprototyp für eine Omnichannel-Kommunikationsanwendung entstanden, die es erlaubt, Nachrichten aus verschiedenen Kommunikationskanälen zu administrieren. JHipster bildet den Grundbaustein der Applikation (React Frontend, Spring Boot Backend). Es stellte sich heraus, dass die Integrationsmöglichkeiten der Kommunikationskanäle stark von den angebotenen Schnittstellen abhängig sind. Mit der entstandenen Anwendung kann der Benutzer Textnachrichten und Anhänge per Mail, mysms und Slack auf einer einzigen Oberfläche empfangen, kategorisieren und beantworten sowie Notizen erfassen. Weiterhin besteht die Möglichkeit, Nachrichten mit einer Erinnerung zu versehen und Chatverläufe zu exportieren. Ein Usability Test mit dem Auftraggeber sorgte dafür, dass die Bedienerfreundlichkeit nochmals verbessert werden konnte. Der erstellte Prototyp wird bereits bei dem Industriepartner erprobt
FNH-CRM – Management tool for fitness studios
Get PDFFor fitness studios and studio chains, customer loyalty is getting more and more important, as the prices for subscriptions cannot get much lower. For a studio to achieve this, a CRM is necessary. The tools on the market are either fitness studio softwares that offer appointment booking but are missing a lot of a CRM functionality or CRM software that misses the needed fitness studio functionality. FNH wants to change this and build a fitness studio software with the CRM at its core.
When a personal trainer works with the current solution, he has to constantly switch between multiple devices, PDF forms and applications. This makes work tedious and costs a lot of time, which could be spent on the customer. In order to optimize these processes, a CRM should be created that combines all the required functions to manage a lead’s or customer’s information digitally in one tool and on one device. This simplifies the analysis with business intelligence tools significantly, because all the information is in one place.
A web-based CRM was developed for the client, which contains the basic functionality. The application makes it possible to follow a potential customer, called lead, through the entire customer acquisition process to the management of a customer. This includes recording various measurements and documentation of the customer, the training or the nutrition, as well as customer interaction reporting. Several functions were implemented to improve customer loyalty. The administrator can create individual processes, so-called workflows, that can be assigned to the leads depending on their requirements. All the lead process steps are recorded for future analysis.
The prototype contains two core components, frontend and backend. Both parts of the application provide all the desired basic functionality and can be easily extended due to the use of well-known web technologies. This includes React for the frontend and Node.js for the backend. For the database, MySQL was used. All application components are hosted as containers in the cloud. The modular design and use of the flexible REST API allows for new functionality to be added to the application in the future
Live Response Training Range mit Velociraptor
Get PDFWith the ever-increasing number of cybersecurity incidents happening world-wide, incident response is becoming a central part of any cybersecurity education training. In response to this, OST is offering a new CAS course named Cyber Security. One recently becoming popular tool for incident response is Velociraptor. The goal of this project was to create training material for students covering incident response practices using Velociraptor and Volatility. Moreover, to simulate a realistic attack scenario, a compromised training range based Microsoft Azure needed to be provided.
For that purpose, a training range designed for offensive security attack scenarios was tailored to suite for the incident response exercises. As was the case with the provided training range, deployment of a new environment is done with Terraform. The virtual machines and Active Directory domain from the existing offensive security training range were largely kept and built upon. New exercises – called challenges – were implemented by adding to existing or adding new Terraform, PowerShell or Python scripts. To facilitate coordinating the simulated attack, a C++ server-client application was developed to simulate the attacker.
In total, 11 challenges were implemented. The challenges are formatted to be included in OST's Hacking-Lab and cover Velociraptor deployment and the forensic analysis of initial access, multiple persistence mechanisms, lateral movement, and privilege escalation. Additionally, students will learn how to perform memory analysis with Volatility and Velociraptor, squid proxy log parsing, and how to clean an infected environment after an attack (eradication). The challenges are designed and ordered in such a way as to guide the students through investigating the cybersecurity incident. Additional challenges can easily be implemented building on the existing environment to simulate additional attack techniques or incident response steps
Fuzzing .NET
Get PDFFuzzing ist eine Form von Software-Testing bei dem ein Programm mit zufällig generierten Daten gefüttert wird. Das Ziel dieser Tests ist es ein abnormales Verhalten des Programmes zu finden das man mit anderen Testmethoden nicht finden würde. Diese Technik ist für das Testen eines XML-Parsers sehr hilfreich, da man so auf Testszenarien/Programminputs kommt, die man sonst nicht in Betracht ziehen würde.
Das Ziel dieser Arbeit ist es, verschiedene Fuzzing Tools mit den dazugehörigen Tool-Chains für die .NET Plattform zu recherchieren und danach auch zu evaluieren, mit besonderer Aufmerksamkeit auf die Eignung der Tools für das Testen von einem XML-Parser, welchen wir von nxt Engineering zur Verfügung gestellt bekommen haben. Ebenfalls ein Teil der Arbeit ist die Evaluation des neuen, von Microsoft entwickelten, Tool OneFuzz.
Um dieses Ziel zu erreichen, wurden zuerst die theoretischen Eigenschaften verschiedener Fuzzing-Tools analysiert. In einem zweiten Schritt wurden die vielversprechendsten Tools in Betrieb genommen und praktisch an einem XML-Parser getestet. Ein Resultat dieser Arbeit ist die Tool-Chain die sich besonders gut eignet, um XMLParser auf .NET Umgebung zu testen und auf was man bei der Einrichtung sowie dem Testen besonders achten muss. Des Weiteren wurden während dem Testen des XML-Parsers von nxt Engineering nur wenige kleine Programmierfehler gefunden
Statistical Analysis of Test Data in Microelectronics Industry
No full textProblem: The international company ams AG is a producer of semiconductors. In order to meet the customer’s expectations ams AG needs to guarantee to only ship parts which meet the specifications. Therefore, several tests will be executed on the parts. The results need to stay within the specification limits. If a part is systematically out of range, a tester needs to analyse the test data. This bachelor’s thesis’ goal is to simplify the process of analysing the cause of faults. ams AG is looking for a tool meeting the following requirements:
1. Scan test data logs and calculate robust measures based on the type of distribution.
2. Create an algorithm which detects and removes outliers. The identified parts are likely defective devices.
3. Build an interactive GUI for analysis and manipulation purposes. This task is optional.
As an asset for development, ams AG provided real project data.
Approach / Technology: An initial data analysis helped to understand the structure of the data and which information could be omitted to improve the performance. With the reduced complexity, multiple tests were performed to identify whether a measure is robust or not.
In parallel, different outlier detection algorithms were compared with each other. Metrics were examined to decide whether or not omitting those outliers have a significant influence on the data.
Finally, appropriate visualisations of the data were developed to optimise the display of the obtained results. These are combined into a report, highlighting the relevant metrics.
Result: A decision tree was built to classify the distributions. Depending on the type of distribution, a matching quality measure was applied. For example using the MAD Cpk is more significant than using the Cpk for skewed and tailed distributions.
The outlier detection was done by applying the squared Mahalanobis distance. The significance of omitting the outliers was measured by the Cook’s squared distance.
Using these metrics, negatively influential data points can be removed and result in more stable distributions.
To visualise the results, an HTML report was built. This offers an overview of the dat
TLS 1.3 for strongSwan: A Client-Side Prototype
Get PDFThe Transport Layer Security protocol (TLS) secures network connections between a client and a server. It encrypts and authenticates data from higher-level protocols such as the Hypertext Transfer Protocol (HTTP), and guarantees that the information transmitted remains confidential and unmodified. The most widely used TLS version today is still version 1.2 from 2008 (RFC 5246), even though 1.3 has been released in 2018 (RFC 8446). The strongSwan project, which is maintained by the University of Applied Sciences Rapperswil (HSR), is an open-source IPsec implementation written in C. StrongSwan features its own TLS stack in the library libtls. It enables client-authentication via various EAP authentication methods (TLS, TTLS, PEAP), which is used to establish an IKEv2 connection. However, libtls supports only TLS up to version 1.2. [Objective] This project aims to implement the client-side of TLS 1.3 in libtls and to update the TLS stack. The concrete goal is to successfully perform a minimal handshake and then exchange application data between a strongSwan client and a server running TLS version 1.3. As part of this minimal handshake, it is necessary to integrate new or adapt existing messages that are exchanged between client and server. In addition, TLS 1.3 requires fundamental changes to the cryptographic mechanisms that enable a secure and authenticated encryption. Until a connection is established, the handshake passes through various states in a state machine. This has considerably changed in the new version, which also implies that the handshake flow and state machine must be adapted too. Our scope includes three optional features: The server-side in a TLS handshake, client-side authentication and remaining non-mandatory extensions. [Result] The updated client implementation in libtls can successfully perform a minimal handshake with a server running TLS 1.3. It has been successfully and extensively tested with external TLS 1.3 servers such as those from Google or Facebook, but also with a local OpenSSL server. During implementation the new cryptographic mechanisms proved to be more difficult that originally anticipated. Especially the HKDF (HMAC-based Extract-and-Expand Key Derivation Function, RFC 5869) was an unexpected major challenge, especially since it is only marginally described in the TLS specification. Due to these difficulties, only the minimal handshake was implemented, the client-side authentication and the server-side was omitted. For future work, the HKDF implementation needs attention: It is functional, but the code needs to be refactored. The features defined as optional, i.e. the server-side and client-side authentication, were not implemented due to time constraints. Still, they are relevant to the strongSwan project and will hopefully be completed as a Bachelor thesis
TLS 1.3 Stack for strongSwan
Get PDF[Introduction]
The Transport Layer Security (TLS) protocol secures network connections between a client and a server. It encrypts and authenticates data from higher-level protocols such as the Hypertext Transfer Protocol (HTTP), and guarantees that the information transmitted remains confidential and keeps its integrity. The most widely used TLS version today still is version 1.2 released in 2008 (RFC 5246), even though 1.3 was released in 2018 (RFC 8446). The strongSwan project maintained by the University of Applied Sciences Rapperswil (HSR) is an open-source IPsec implementation written in C. strongSwan features its own TLS stack encapsulated in the library libtls. It enables communication-authentication via various EAP authentication methods (TLS, TTLS, PEAP) used to establish an IKEv2 connection. A client-side TLS 1.3 prototype stack was implemented in the preliminary work before this thesis. However, libtls does not yet fully support TLS 1.3 in the sense strongSwan requires.
[Objective]
The goal of this bachelor thesis is to implement the TLS 1.3 server-side protocol stack, add support for mutual authentication to enable client authentication in a TLS 1.3 handshake and lastly add support for PSK-based session resumption with TLS 1.3. The former two tasks are mandatory features to make the new TLS 1.3 implementation useful for the strongSwan project and the latter is an optional feature. To achieve these goals, it is necessary to integrate new or adapt existing messages that are exchanged between client and server. In addition, TLS 1.3 requires fundamental changes to the cryptographic mechanisms that enable a secure and authenticated encryption.
Until a connection is established, the handshake passes through various states in a state machine. The state machine has considerably changed in the new version, which also implies that the handshake flow and state machine must be adapted. Moreover, the way cryptographic keys are generated and derived by each peer has fundamentally changed, this also needs to be addressed in this work.
[Result]
TLS 1.3 was successfully implemented and provides a server-side stack and mutual authentication. The TLS 1.3 client-side stack, which was implemented already in the preliminary study term project, was improved significantly. Additionally, smaller but important features such as support for KeyUpdate or HelloRetryRequest messages were implemented. The client and server implementations have been extensively tested against each other and also with external servers and tools such as OpenSSL. The mandatory goals were achieved. The optional goal, the PSK-based session resumption, was not implemented fully due to time constraints but the foundation has been laid: The cryptographic logic encapsulated in the HKDF implementation is able to provide all the necessary secrets. However, the communication protocol and logic implementation remains open to further work. Nevertheless, the current implementation is usable and provides TLS 1.3 secured communication for the strongSwan project