Göm menyn

TDDD82 Projekttermin inklusive kandidatprojekt: Säkra, mobila system

Kandidatarbeten

Projekt ID Studenter Handledare
Projekt 1Simin Nadjm-Tehrani
Projekt 2Simin Nadjm-Tehrani
Projekt 3Christian Luckey (chrlu350)
Henning Hall (henha972)
Simin Nadjm-Tehrani
Projekt 4Joakim Eriksson (joaer931)
Samuel Nilsson (samni698)
Simin Nadjm-Tehrani
Projekt 5William Danielsson (wilda168)
Sebastian Waldmann (sebwa513)
Simin Nadjm-Tehrani
Projekt 6Elias Kärnsund (elika798)
Jakob Bäcklund (jakba274)
Niklas Carlsson
Projekt 7Johanna Thorheim (johth976)
Anna Boyer de la Giroday (annbo119)
Niklas Carlsson
Projekt 8Niklas Carlsson
Projekt 9Matteus Hemström (mathe136)
Anton Niklasson (antni325)
Niklas Carlsson
Projekt 10Milad Barsomo (milba894)
Mats Hurtig (mathu837)
Niklas Carlsson
Projekt 11Emmie Nilsek (emmni708)
Christoffer Olsson (chrol563)
Niklas Carlsson
Projekt 12Sofia Nyberg (sofny951)
Robert Krogh (robkr627)
Marcus Bendtsen
Projekt 13Jonas Skog Andersen (jonsk197)
Ammar Alderhally (ammal617)
Marcus Bendtsen
Projekt 14Tomas Melin (tomme578)
Tomas Vidhall (tomvi780)
Marcus Bendtsen
Projekt 15Ludvig Fischerström (ludfi239)
Niclas Hansson (nicha094)
Alexander Lantz (alela654)
Marcus Bendtsen
Projekt 16Hans Hugo Hedelin (hughe531)
Petter Arding (petar239)
Marcus Bendtsen

Instruktioner

Varje par skriver i ett mejl en sorterad lista över alla lediga projekt i sin egna preferensordning. 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 som inte redan är tagna måste ingå i listan (de som redan är tagna är studenternas egna förslag som blivit godkända). T ex:

Marcus Bendtsen (marbe800)
Jakob Pogulis (jakpo779)

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

Specifika krav

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

Projekt

Projekt 1

Ni har implementerat ett system genom att följa en följsam (agile) process från "kundens" beskrivning i text till kod. I en modellbaserad utvecklingsprocess finns det ett mellanläge där design för ett system är representerad i ett modelleringsspråk (typisk exempel i som relaterar till UML familjen av språk). Denna design kan analyseras, ibland verifieras eller simuleras innan kod skapas för systemet. Tanken är att fel i design är svårare (dyrare) att rätta till efter att koden har genererats, och analys av designen kan uppvisa dessa fel i ett tidig stadium (därmed relaterar till pålitlighetsbegrepp som "fault prevention", "fault detection"). Detta miniprojekt går ut på att ta fram en design modell för systemet som ni implementerat. Dels för att lära sig hur denna aktivitet bedrivs och förstå det skapta systemet bättre (och dokumentera designbesluten), dels för att försäkra sig att systemet som har skapats uppfyller de egenskaper som skulle kunna påvisas redan i ett design stadium (därmed skulle kräva mindre testning senare ifall man hade analyserat designen). Den design verktyg som är tänkt att ni ska använda är Arctis (http://www.item.ntnu.no/_media/academics/courses/ttm4115/ttm4160-arctis-2012.pdf).

Projekt 2

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 implementeringsfasen har ni inte haft kravet att kvantifiera ("justify") hur stor tillgänglighet ni kan garantera och detta under vilka omständigheter (vilken felmodell, hur ofta kan felet uppträda, och under vilken last från klienterna). I detta miniprojekt ska ni ta fram en matematisk modell genom användning av tidigare kunskaper i sannolikhets teori och andra källor i litteraturen. Modellen ska kunna användas för att prediktera hur tillgänglig er server är och ni ska kunna välja lämpliga parametrar i er server replikeringsmekanism (tex den optimala intervallet för "checkpointing") för att åstadkomma den önskade nivån av tillgänglighet, eller önskade snabbhet iåterhämtning efter en krasch.

Projekt 3

Er app är tänkt att kunna adaptivt ändra sitt beteende och använda mindre energi när det visas en batterinivå som indikerar att erhållna QoS ska anpassas. I implementationen har ni fokuserat på en första realisering för denna klientbeteende. I detta miniprojekt är det tänkt att ni tar fram en matematisk modell som karakteriserar er apps anpassningsförmåga. Modellen ska kunna användas för att avgöra hur olika regler ("policies") för packet sändnings ("forwarding mechanisms") leder till olika batterilivslängd givet en viss transmissionsenergikostnad. Minst två olika schemaläggningsmekanismer ska modelleras så att beslut ska kunna fattas om den ena eller den andra leder till längre batteri tillgänglighet (därmed livslängd för din "device") givet ett givet paketflödesprofil. Minst en ny implementering av anpassningsmekanism på klientsidan framtas.

Projekt 4

Applikationen som ni demonstrerar använder 3G överföring i er testmiljö. Det är vanligt att riktig mobilitet förknippas med cellulära nätet (3G, LTE) även om många appar körs över WiFi då den har lägre överföringsenergi avtryck. Ett krav i er tillämpning är att systemet ska vara energisnål i de handburna enheterna, och energieffektivitet i 3G 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 använda en Kit som Ericsson tillhandahållit för att kunna mäta den exakta energiåtgången för olika appars interaktioner över 3G-nätet. Eftersom repeterbara experiment med olika appar för att mäta deras energiavtryck är både svårt och tidskrävade, 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ång. I detta miniprojekt ska ni lista ut hur ni kan generera lämpliga (representative) transmissionsspår från er app och hur ni kan mha vårt verktyg avgöra appens energiavtryck.

Eftersom olika grupper har olika klienter och olika interaktioner så kan detta projekt göras i 4 olika par-grupper som använder 4 olika appar och då får grupperna olika mätresultat som de kan jämföra med varandra. Notera att två par från samma projektgrupp kan inte genomföra detta arbete. Projektet kräver också att ni har var sin laptop i paret.

Projekt 5

(Context-aware energy-efficient instant messaging - finns även på rtslab webbsida) With the advent of smartphones Instant Messaging (IM) applications have become highly popular and are commonly used to send short texts as well as multimedia messages. Unfortunately, their energy consumption due to data transmission is quite high. The aim of this project is to study how the knowledge about user activity information, user context information (e.g., built-in sensors) and/or IM protocol information can be used to achieve energy efficiency for IM applications. This study can be extended to other networking applications as well. The components of the thesis project are the following: 1) Survey the activity and context information that is available in current mobile devices, 2) Study the potential for using the additional information, in terms of energy saving, given the energy overhead of collecting it, and 3) Propose and implement an energy-efficient solution for an IM application.

Projekt 6

Implementation of a crowd-based information sharing system for network performance maps. Network performance maps can be used to predict the bandwidth conditions will see in a particular location. By leveraging measurements made by many users that have been in similar locations as a user, the network performance maps used by a user can be enhanced compared to if only using its own measurements. In this project you are expected to (i) build a proof-of-concept implementation of a peer-to-peer system (possibly proxy assisted) that allow wireless android devices (e.g., your phones) to exchange throughput measurement data with other neighboring devices, (ii) perform multi-mobile experiments that clearly captures the performance of your implementation and how well it works. The implementation should allow throughput data and geo-location data to be collected at the device according to the format briefly described in the short paper "Geo-location-aware Emulations for Performance Evaluation of Mobile Applications". Whoever picks this project should be a strong programmer and is expected to be able to do the coding and implementation relatively independently. My preference would be that the system operates over WiFi.

This project requires some coordination with project 7 and 8.

Projekt 7

Simulation of location-aware information sharing policies for crowd-based information exchange systems. Crowd-based information sharing can be used to improve the knowledge of the participating machines. For example, motivated by the exchange of "geo-throughput" information as used in project 6, you can envision that machines information about geo-history-based throughput information (e.g., of WiFi throughput measurements on different locations on campus). In this project you should (i) build a simple simulator that allows you to test and compare different exchange policies, and (ii) design and evaluate both basic and more advanced policies that determines (a) who should exchange information with who (e.g., based on where you and them have been), (b) at what times these exchanges should take place (e.g., when you both are in the same location for some time), and (c) what information should be exchanged (e.g., throughput for locations of common interest). Your simulator should take a set of mobility traces of clients (that you use for both past history of where they have been and future history of where they are going) and use these to simulate and compare different policies. (Note that the focus on this project is on the difference in value of the exchanged information when using different policies.) The first milestone will be to have the simplest possible policy that you can share with project 8.

This project requires some coordination with project 6 and 8.

Projekt 8

Creating realistic mobility patterns and analyzing their impact on opportunistic information sharing. In the context of the exchange of geo-based throughput information, for example, as in projects 6 and 7, the mobility pattern of the users play a critical role in how beneficial the information that is being exchanged will be for the different users. In this project you will (i) build a mobility trace generator that allow you to generate both simple/basic and more realistic mobility scenarios, and (ii) build a simple simulator that allows you to test and compare a basic information exchange policy under different mobility patterns. (While the code ideally should allow you to plug in other exchange policies, the focus on this project is on the mobility patterns.) In addition to surveying the existing literature for mobility patterns, I would like to see the mobility patterns to be based on student's mobility on Campus Valla. For example, can we find schedules for different student groups (e.g., based on class sizes in different programs and their schedules) and approximate the general mobility patterns of students, by treating lecture rooms as a single location, for example? The first milestone will be to have a trace with a very simple mobility patterns (e.g., daily or weekly repletion of random waypoint) that can be shared with project 7. At this time the trace format should be finalized so that both groups use the same API. It is also expected that the motivating scenario is exchange of "geo-throughput" information as used in project 6 and similar types of geo-history-based information.

This project requires some coordination with project 6 and 7.

Projekt 9

A measurement study of the second channel during the Eurovision contest (or other big TV contests). With quick and easy mobile access Twitter have become a popular means to express opinions about current events as they happen. In this project you are expected to (i) build a measurement methodology and perform large-scale measurements using the Twitter API to estimate and characterize the use of Twitter as a "second channel" before, during, and after the broadcast of a popular TV contest (e.g., the Eurovision contest) seen in (one or) many different countries, and (ii) put the collected data into easy-to-analyze (text) format, and (iii) perform an initial preliminary analysis of the data, so that you can present concrete results. Ideally, the hope would be to have the methodology set up and tested well before the Eurovision song contest (e.g., during the popular TV contest (such as "Lets Dance") on weekends, and/or post processing of past national competitions and other popular contests. The methodology should then be used to collect data about Eurovision contest. Ideally, the methodology should allow you to distinguish activities associate with different topics/contestants, activity associated with posters located in different regions, etc. Using this data and the voting in different countries (should be available for the final, as well as the national completions, I suspect) you can evaluate how well the results compare with popularity Twitter, for example. (Similarly, for national completions, it may be worth trying to find the results from the national and international TV show(s).) Perhaps the main research questions to answer here is if Twitter feeds can be used as a predictor of the results of these shows. (Ideally, this question should be answered both at a national and international level.)

Projekt 10

Mobile Web Adaption There is an ongoing debate if websites should create a separate website version for different mobile users, or if they should allow the users to select what content they view themselves, regardless of what device they use. As of today, different companies takes different stands on this, and make relatively different efforts to adapt their websites for mobile clients with different device types. In this project you are expected to (i) develop a measurement methodology that captures if and how different websites (e.g., the most 500 most popular websites on the Web) adapt to different devices, (ii) collect datasets, (iii) put the collected data into easy-to-analyze (text) format, and (iv) perform an initial preliminary analysis of the data, so that you can present concrete results. For the data collection task you will likely need to create a tool that modify the HTTP get requests made by a test machine that emulate the requests made by different machines, mobile devices, etc. You will also need to do a fair bit of active measurements, and analysis of the collected traces.

Projekt 11

Kommunikation utan gränser - hur man sätter upp ett effektivt Ad-Hoc nätverk.är en krissituation uppstår kan det vara livsviktigt att man snabbt kan sätta upp ett kommunikationsmedium på kort tid. Detta vill vi koppla till projektet genom att fördjupa oss i hur kommunikationen fungerar när en krissituation uppstår. Vi vill undersöka hur man sätter upp ett nätverk och använder det på bästa sätt. Vi vill också fördjupa oss i inom kommunikationen är ad-hoc nätverk och undersöka skillnader mellan olika typer av routing-protokoll. Det vi vill utgå ifrån är ett scenario och sedan gå igenom ett effektivt arbetssätt för att sätta upp förlorad kommunikation med hänsyn till begränsade resurser. Vi kommer att göra detta på ett eget sätt utifrån vad vi lärt oss och ta hänsyn till existerande forskning.

Ericsson hade en föreläsning om hur de hjälper till med kommunikation vid olika krissituationer runt om i världen och det väckte vårt intresse att undersöka hur detta fungerar närmare. Syftet med arbetet är att erhålla en djupare förståelse för hur man kommunicerar under en krissituation. En annan intressant aspekt är att undersöka hur denna kommunikation skulle kunna utföras mer energieffektivt då resurserna är begränsade ute på uppdrag.

Vad är ett ad-hoc nätverk? Hur går man till väga när man sätter upp ett nytt nätverk på kort tid? Går detta tillvägagångssätt att förbättra? Vilka ad-hoc-protokoll används idag? Hur fungerar dessa protokoll och vad är skillnader mellan dem med hänsyn på energieffektivitet? Hur fungerar implementationen av dessa protokoll? Hur kan man göra för att använda resurserna så effektivt som möjligt i framtiden? Hur gör man när det är svag täckning för att utnyttja den så effektivt som möjligt? o Hur gör man för att batteriet ska användas så effektivt som möjligt?

Projekt 12

När modern teknologi utmanar gammal kryptoteknik. I århundraden har människor försökt hemlighålla information från oönskade ögon och öron. Uråldriga tekniker att gömma meddelanden på olika sätt har genomåren utvecklats till vad vi idag kallar kryptering. Många tekniker som på sin tid ansågs olösbara klarar dagens datorer av att lösa inom rimlig tid. Det finns dock undantag. Genom historien har en rad krypton skapats som än idag får de skarpaste krypoteknikerna att klia sig i huvudet. Ett av dessa krypton är det berömda Bealekryptot. Historien om Beale berättar i sann "National Treasure"anda om att en stor skatt grävdes ned någonstans i USA år 1819 och 1821. De tre krypterade dokumenten finns bevarade än idag, men två av dem har förblivit olösta. Det andra dokumentet, som är det lösta, beskriver vad skatten innehåller, vilket i dagens penningvärde är värt mer än 63 miljoner amerikanska dollar. Detta var ett modifierat bokkrypto som löstes med hjälp av USA:s självständighetsförklaring (eng: United States Declaration of Independence). Mycket talar för att de övriga två dokumenten, är krypterade enligt samma princip, men det har inte gått att använda samma bok till dessa.

Vår idé är att försöka ta oss an detta krypto med hjälp av list och modern teknik. Idag finns mängder av litteratur datoriserad, vilket skulle kunna snabba upp processen att försöka dechiffrera dokumenten. Genom att skapa en algoritm som applicerar den krypterade koden på olika litterära verk utgivna före 1822 och därefter använda oss av någon form av språkigenkänning för att se om det vi funnit skulle kunna vara en vettig lösning.

Eftersom kryptering är en så stor del av modern datoriserad säkerhet skulle det vara en intressant jämförelse att titta på historiska exempel som än idag upprätthåller sitt syfte att hemlighethålla information. Med modern teknik har vi tillgång till hjälp och hjälpmedel som tidigare varit otänkbart. Syftet med inriktningen är att få en fördjupad förståelse för kryptografi och dess användning både nu och då och i framtiden kunna implementera kunskapen i vårt kommande ämbete.

Kan vi med hjälp av modern datorteknik hitta nya sätt att ta oss an olösta krypton?

Projekt 13

DoS attacker Vi har tänkt att bygga vårt arbete utifrån en litteraturstudie och en implementation. Till en början ska vi göra en noggran litteraturstudie av DoS attacker. Detta för att skapa en bra förståelse för vilkan typ av DoS attack som går att implementera verkligt i en simulerad miljö. Vi kommer välja en lämplig attack att fördjupa oss i samt implementera den.

De frågeställningar vi har inför projektet är: Hur lätt är det att göra en lyckad DDoS attack? Hur gör man en Dos attack? Vilka medel behövs för att göra en DoS attack? Vilka olika typer av DoS attacker finns det? Går det att skydda sig mot en DoS attack? I så fall hur och i vilken utsträckning?

Projekt 14

Vilka hot finns mot krypteringsmetoder som använder sig av asymmetrisk kryptering? Asymmetrisk kryptering är en metod för att kommunicera säkert. Detta fungerar genom att man har två nycklar, en publik och en privat. Den publika nyckeln är känd för alla men den privata måste vara hemlig. Alla kan kryptera meddelanden med en publik nyckel men de kan bara dekrypteras med hjälp av den privata nyckeln. Denna metod används idag inom bland annat RSA-kryptering. Problem som kan uppstå med denna metod är autentisering av publika nycklar.

Vi vill få reda på mer om hur man kan kryptera data på ett osäkert nätverk genom att använda asymmetrisk kryptering. Vi vill också ta reda på hur säker denna metod är och om vissa hot fortfarande finns kvar.

Hur fungerar asymmetrisk kryptering? Hur har asymmetrisk kryptering historiskt sett förändrats då olika implementationer har knäckts? Vilka sorts attacker är asymmetriska krypteringsmetoder sårbar mot? Vad kan man göra som "Man in the Middle"? Kan man motverka dessa attacker med autentisering? Hur fungerar Diffie-Hellmans metod för nyckelutbyte? Vilka sorters attacker är Diffie-Hellman sårbar mot? Varför vill man kryptera symmetriskt när man redan kan kommunicera med asymmetrisk kryptering?

Projekt 15

Inteligent teknik är på väg in i våra hem, men redan i de första produkterna har man hittat säkerhetshål. I och med att Google går och köper upp företag som sysslar med smart hemelektronik så är det mer eller mindre bestämt att denna produktkategori kommer vara en naturlig del av vanliga människors hem inom ett par år. Detta i kombination med den nu allmänt kända övervakningen som sker runt om i världen finns det all tänkbar potential att dessa typer av produkter i framtiden kommer att missbrukas och därmed utgöra stora säkerhetsrisker. I en vinstdriven och komptetativ värld som vår så är riskerna att företag tummar på säkerhet stor då detta håller dem borta från lansering av produkten.

Vad vi kan finna i våra undersökningar är att detta är ett ämne som ännu inte är särskillt utforskat. Vi vill därför genom detta arbete belysa de potentiella säkerhetsrisker som denna produktkategori skulle kunna medföra. Att öka branchens och allmänhetens medvetenhet om riskerna är en nödvändighet för att dels säkerställa individers integritet och säkerhet.

Då det inte går att förutsätta att nätverket som produkten är anslutet till är säkert så kommer vi att avgräsa oss till att vi redan är anslutna till samma näverk som produkten vi försöker hacka.

Vi ska utföra riskanalyser på 3-4 produkter som ingår i kategorin "Smarta hem". Metoden vi kommer att använda oss av för riskanalys är CORAS. Utifrån riskanalyserna kommer vi att välja n hot och försöka att utnyttja dessa. Då vi inte har tillgång till några produkter kommer vi att kontakta företag som har produkter i den sökta kategorin på jakt efter demo-produkter. Om detta inte ger något resultat kommer vi att antingen inhandla produkter eller utföra riskanlyserna utan fysisk tillgång till produkterna. Eftersom vi ska utnyttja en av riskerna så kommer vi minst behöva en fysiskt produkt.

Vad finns det för risker med de produkter vi kommer att undersöka? Vad har produkter inom kategorin för säkerhet idag?

Projekt 16

Spridning av malware. Idag laddar vi ner och delar filer mer än någonsin vilket också medför att det sprids mer och mer skadlig mjukvara. Den vanliga användaren tar i regel naivt för givet att filerna och programmen de laddar ner och kör är harmlösa. De har lärt sig att om man laddar ner från "säkra" källor, såsom Appstore, så näst intill garanteras man malware­fria applikationer, program och filer. Detta inbringar en falsk trygghet för användarna att ladda ner vad de önskar utan att tänka på konsekvenser. Men det de flesta användarna inte vet, är att det inte går att garantera att allt de laddar ned är helt harmlöst. Ett systems säkerhetsmekanismer kommer aldrig kunna täcka alla säkerhetspolicies, och därmed aldrig vara helt säkert.

Vilka är de bästa metoderna för att få malware att inte upptäckas av diverse antivirusprogram och brandväggar? Hur fungerar de bästa spridningsmetoderna för malware idag och hur de kan tänkas utvecklas i framtiden? (för att förbereda sig inför framtida spridning) Vilka målgrupper ska man rikta in sig på för att sprida så mycket och skadlig malware som möjligt? Kan vi själva designa och utforma malware som undviker detektion?


Sidansvarig: Nahid Shahmehri
Senast uppdaterad: 2014-03-26