Göm menyn

TDDD82 Projekttermin inklusive kandidatprojekt: Säkra, mobila system

Kandidatarbeten

Projekt ID Studenter Handledare
Projekt 1 Martin Larsson (marla396)
Anton Silfver (antsi451)
Mikael Asplund
Projekt 2 Erica Gavefalk (eriga605)
Per Gustavsson (pergu627)
Mikael Asplund
Projekt 3 Rickard Hellenberg (riche828)
Oskar Gustafsson (oskgu360)
Simin Nadjm-Tehrani
Projekt 4 Johan Sjöstrand (johsj748)
Sara Westberg (sarwe746)
Simin Nadjm-Tehrani
Projekt 5 Simin Nadjm-Tehrani
Projekt 6 Marcus Arnemo (marar554)
Benny Lam (benla241)
Niklas Carlsson
Projekt 7 Markus Johansson (marjo688)
Sebastian Andersson (seban649)
Niklas Carlsson
Projekt 8 Rasmus Jönsson (rasjo008)
Summia Al-mufti (sumal598)
Niklas Carlsson
Projekt 9 Carl Nykvist (carny499)
Linus Sjöström (linsj405)
Niklas Carlsson
Projekt 10 Filip Polbratt (filpo653)
Olav Nilsson (olani913)
Niklas Carlsson
Projekt 11 Elina Lundberg (elilu003)
Cecilia Malmrud (cecma733)
Marcus Bendtsen
Projekt 12 Oscar Pap (oscpa453)
Per Lindström (perli944)
Marcus Bendtsen
Projekt 13 Hanna Sterneling (hanst665)
Elias Alesand (elial148)
Marcus Bendtsen
Projekt 14 André Lehto (andle349)
Isak Sestorp (isase446)
Marcus Bendtsen
Projekt 15 Jesper Persson (jespe186) Marcus Bendtsen

Instruktioner

Varje par skriver i ett mejl en sorterad lista över alla projekt (högst prioriterad först). I mejlet skall också framgå vilka två personer som ingår i gruppen. Bifoga inte några dokument eller liknande, allt ska stå direkt i mejlet. Notera att alla projekt måste ingå i listan. Mejlet skall se ut som följande exempel:

Marcus Bendtsen (marbe800)
Jakob Pogulis (jakpo779)

Projekt 4
Projekt 1
Projekt 8
osv.

Kursledningen kommer sedan att dela ut kandidatarbeten. Vi utgår från era preferenser men kan inte garantera att ni får de projekt ni har satt högst på listan.

Språk

Eftersom dessa kandidatarbeten har en vetenskaplig karaktär så föredrar vi att arbetena genomförs på engelska. Framläggning och opposition är på svenska.

Specifika krav

Vissa projekt har specifika krav, de står skrivna i texten till projektet, se till att ni uppfyller dessa.

Projekt

Projekt 1

Feldetektering
Detta projekt går ut på att analysera möjliga realisationer av feldetektering av mobiler och/eller server-replikas i ett disaster scenario. Förutom att titta på lämpliga (eventuellt optimala) tidsgränser för timeout i ett dylikt system är det också möjligt att ta hänsyn till om noden befinner sig i ett område som historiskt har dålig täckning, eller om den är nära andra noder som också har fallerat. Detta kan göra att detekteringen får bättre prestanda än om dessa faktorer inte räknas in.

Projekt 2

Gemensamt tillstånd
Detta projekt går ut på att använda en gruppkommunikationslösning (som utvecklats i ett tidigare kandidatprojekt) för att alla klienter ska komma överens om vilken av två möjliga servrar att använda (primär eller sekundär server). Lösningen ska utvärderas med i hur stor andel av fallen som klienterna använder samma server (i fall då primärservern går ner), samt om lösningen orsakar fördröjning även i fall då inget fel finns.

Projekt 3

Feltolerans och dess påverkan på prestanda
Er centrala server för missionshantering och lägesbild är en typisk kritisk funktion som man ställer hög tillgänglighet krav på. I den tidiga utvecklingsfasen har ni karakteriserat vilka antaganden ni har om felkällor (faults) som kan påverka hur tillgänglig denna tjänst är. Oavsett hur långt ni kommit för att implementera en feltolerant version av er server, så finns det behov av två fördjupningar i detta miniprojekt: a) att slutföra implementeringen av redundansen så tjänsten kan påstås ha högre tillgänglighet än en icke-feltolerant server, och b) skapa lämpliga experiment så att ni kan mäta hur den feltoleranta tjänstens prestanda (tex average/max round trip time) påverkas jämfört med den icke feltoleranta tjänsten.

Projekt 4

Systematisk testning av Android applikationer
Att testa en applikations tillförlitlighet är ett teoretiskt svårt problem. I princip ska alla möjliga inputs till applikationen genereras för att kunna säkerställa att appen gör vad den ska. Men mängden testfall blir lätt stor på grund av kombinatorisk explosion. I detta projekt ska ni dels kartlägga vetenskapliga ansatser för att testa mobila applikationer med avseende på funktionella krav och valda säkerhetskrav, och dels tillämpa någon befintlig ansats (med tillhörande programvara) för att testa er applikations systematiskt. Om applikationen måste färdigställas innan olika funktioner kan testas så ingår detta också i arbetet. Men åtminstone tre olika funktionaliteter från kravlistan måste testas fullständigt och resultaten sammanställas systematiskt. Dessutom ska applikationen testas med avseende på säkerhetskrav (konfidentialitet och integritet), dvs kan en obehörig komma åt/ändra data som de inte har rätt till? Normalt brukar man kalla dessa tester penetrationstester, och en del av arbetet utförs genom att konstruera attack scenarier.

Projekt 5

Energifotavtryck för trådlös kommunikation i krisscenarier
Applikationen som ni demonstrerar ska kunna använda 3G/4G eller WiFi för överföring av krislägesinformation. Ett krav i ett krissammanhang är att systemet ska vara energisnål i de handburna enheterna, men energieffektivitet i 3G/4G nätet påverkas stort av både mängden överföringar och distribution av paket upp/nerladdning över tiden. I detta miniprojekt är det tänkt att ni ska mäta den exakta energiåtgången för en apps interaktioner över 3G/4G/WiFi-nätet. Eftersom repeterbara experiment med olika appar för att mäta deras energiavtryck är både svårt och tidskrävande, så har vi ett verktyg - EnergyBox - som tillåter att interaktionen med en app ("packet traces" för appen) ska kunna användas för att estimera energiåtgången. I detta miniprojekt ska ni identifiera metoder för att systematiskt generera olika transmissionsspår - dvs olika typer av paketflöden, t.ex. text, bild, video, röst - från er app, använda verktyget för att på ett mer systematiskt sätt avgöra appens energifotavtryck. Applikationen behöver eventuellt färdigställas *innan* dessa mätningar utförs så att ni faktiskt kan generera typiska paketflöden i ett realistiskt scenario innan deras energiavtryck mäts.

Projekt 6

Implementation and Instrumentation of a Branched Video Streaming Player using Dash.js
We have designed and implemented a novel media player that allows interactive video to be stitched together in ways that allow users to interactively select different non-linear media paths through the media. Our current framework uses Adobe's Open Source Media Framework (OSMF) and was originally presented at ACM Multimedia 2014. In this project, you are expected to implement a hopefully improved version of the player using the (open source) DASH.js framework (instead of OSMF). We have some ideas for improvements that we hope to implement and test in this new version ... The goal of this project would be to implement a demonstrator using DASH.js and to extend some specific feature of the player. At a high level, the extensions will include careful prefetching and improved buffer management. Good program skills (and some systems work to setup an experimental testbed) are expected to be needed to successfully complete the project.

We are planning to sign an agreement that ensure that we keep the intellectual property rights to the design and the software. The goal would be to create a demonstrator of our software, which eventually will be made available with the next academic publication. Your contributions will be properly acknowledged and the publication process should not hinder you from publishing your thesis. (Explanation: The code is expected to be non-public until a research article eventually is published based on the software, at which time we would plan to release the source code (and acknowledge the people that have contributed and helped with the code). Until that point in time, the code and any technical solutions and ideas should remain non-public.)

Projekt 7

Implementation and Instrumentation of a of an Interactive Video Streaming Player with Dash.js
Essentially the same as Project 6, but for a somewhat different application, based on a paper currently under submission, in which clients can switch between different camera angles of the same event, for example. Also here, our implementation is in OSMF, we have ideas for improvements, and would like to implement things using Dash.js instead. Similar to the first project, the extensions will include careful prefetching and improved buffer management. Again, good program skills (and some systems work to build a good testbed) are expected to be needed to successfully complete the project.

Again, we are planning to sign an agreement that ensure that we keep the intellectual property rights to the design and the software. The goal would be to create a demonstrator of our software, which eventually will be made available with our next academic publication on the topic. Your contributions will be properly acknowledged and the publication process should not hinder you from publishing your thesis.

Projekt 8

HTTP2, Server Push, and Branched Video
Project 6 and 7 are both client driven and can be run with any HTTP server. In this project, we will instead look at solutions on the server side. In particular, we will look at if branched video (see ACM Multimedia 2014 paper and branched video project above) can be effectively served with the help of server-push features in HTTP2, rather than with client-driven prefetching. The client would still need to present the user with playback path options and where to switch to different alternatives. However, the intelligence would now be placed on the server side which actively push content that the client is likely to need in the future. Ideally, we would like to look at hybrid approaches too which involves both client-based prefetching (potentially with some sharing of buffer conditions) and server-based push.

This project is more system oriented and will require some systems skills. For example, you will need to setup and configure servers to work with HTTP2 and server-push. Also here, a testbed need to be implemented for the performance tests (involving server, client and network). Again, ideally if the project is successful, we would like to take similar steps to ensure that a paper potentially could be published based on this project.

Projekt 9

Performance Impact of HTTPS and Certification Transparency Checks
Effective and secure communication is essential in everyday life, but perhaps even more so in emergency situations. In a recent initiative, Google and other organizations have pushed for the use of Certificate Transparency (CT). In this initiative, certificates are expected to be logged in publically audible CT logs. Furthermore, servers are expected to provide clients (i.e., the browsers) proofs that the certificates have been logged in CT logs. Already today, Chrome demands that Extended Validation (EV) certificates (issued after Jan. 1, 2015) are logged before displaying visual cues to the user that normally come with EV certificates. In this thesis project, you are expected to setup a testbed that allows us to evaluate the performance impact of using HTTPS in general, but especially when using CT checks and the impact of how the Signed Certificate Timestamps (SCTs) are delivered, where the SCTs can be delivered in different ways and are used to prove that a certificate has been logged. You are also expected to setup a measurement infrastructure to analyze the handshaking that takes place with regular web servers. This include active measurements to the servers observed when connecting to the most popular websites in the world, different categories, or both. The project should result in a solid measurement methodology, a substantial and sound dataset, as well as a preliminary analysis of the collected data. We are interested in both the how this is implemented in practice, as well as potential performance penalties that comes with CT. (As with the code projects above, the dataset and tools should not be shared publically until we potentially publish a research article using these tools and datasets.) For additional information about CT we suggest reading our PAM 2017 paper (http://www.ida.liu.se/~nikca89/papers/pam17.pdf), watch the following YouTube video for some motivation why CT is important (https://www.youtube.com/watch?v=4GQLvogFGO4), or both.

Projekt 10

Twitter project looking at popularity dynamics (and influencers at events, for example)
You will help extend and improve a data collection framework that we have started to develop, so to answer a number of research questions related to popularity dynamics in news content (as seen with the help of twitter). The research questions will be discussed offline, but the framework, use both the twitter API and the Bit.ly API (for url shorteners). In this project you will develop an improved crawling/parsing tool that extract bit.ly URLs from Twitter posts and then classify them based on different criteria. You will need to develop a methodology that safely (with limited risk to the crawler) classifies a website (pointed to by the shortener). You should also work with the Twitter API to extract bit.ly URL shorteners. The final product of the project is a crawling/parsing tool that identifies and classifies bit.ly URLs (and the landing websites) that can be used for further studies, collect a large longitudinal dataset (according to a methodology that we can discuss in person), and perform a preliminary analysis that show that the dataset is sound and can be used to help answer some example questions. (As with the code projects above, the dataset and tools should not be shared publically until we potentially publish a research article using these tools and datasets.) This project require good programming skills and willingness to work with other people's code. Familiarity with using web APIs is also recommended.

Projekt 11

Survey of companies internal security
Producers of software and hardware products are often required to consider the vulnerabilities that their own products may have. However, this project aims to map how companies work with security questions relating to internal praxis. For instance: How are the employees protected from malware? Are their routines for information sharing across departments?. Students taking on this project should contact as many companies in the Linköping area as possible, and conduct an interview with each of them. The report is a summary of how the companies work with internal security. Note that students are expected to contact the companies on their own.

Projekt 12

Certificate mapping
This project aims to map the current status of certificates used by publicly available services. Students are expected to create a tool that can scrape certificates from web servers, and to extract interesting information from these. For instance, it may be interesting to estimate a distribution over which cryptography algorithms are supported etc. Students should have good network and programming skills so that they can develop the tool independently.

Projekt 13

Graphical passwords
There has been a lot of research in the field of graphical passwords. They can offer two desirable qualities: easy to remember and hard to "shoulder surf". The aim of this project is to review the current academic litterature on graphical passwords, and then to implement a system for graphical passwords. Students should conduct experiments of their system to assess the ease at which passwords are remembered, and to be able to demonstrate in a live setting that "shoulder surfing" is harder than using normal text based password.

Projekt 14

Risk analysis of mobile clients
Which threats exists against mobile clients? What are the state-of-the-art attacks that can be performed, and how common are they? This project is a litterature review of threats against mobile clients. The students are expected to conduct an in-depth riskanalysis, looking into diverse areas such as QR-code vulnerabilities, application mirroring, etc.

Projekt 15

Remote mobile device attestation
Attestation is a method to ensure that a machine (e.g. a server) is running exactly the code that the user expects, to ensure that malware has not been introduced during the boot sequence or later. This can be done remotely so that the user does not have to have physical access to the machine. However, for a company where employees are given mobile devices on which they can install applications, the problem is not easily solved. Employees may, unknowlingly, install applications that contain malware, yet the security responsible department may not be able to tell that the mobile device has been infected. This project aims to develop a system for remote attestation of mobile devices, such that the department responsible for security can scan all mobile devices in circulation. The project requires both a review of potential vulnerabilities, and a proof-of-concept of a system that remotely attest devices.


Sidansvarig: Nahid Shahmehri
Senast uppdaterad: 2017-02-17