Child pages
  • Projects, spring 2017
Skip to end of metadata
Go to start of metadata
  • 2017-01-10: Project topics published.
  • 2017-01-19: Deadline for forming pairs (if possible) and selecting top 3 project topic preferences (
  • 2017-01-26: Project topics assigned (first meeting). 
  • 2017-03-02: Mid-point project presentations.
  • 2017-03-21 & 03-23 & 03-28 & 03-30: Final project presentations.
  • 2017-04-04: Final project report due. Extended to 2017-04-09

Mid-point Presentation

Part way through your project, each project team must give a 10-minute mid-point presentation. The goal of this mid-point presentation is to monitor your progress and give you advice on your work, ensuring that you are progressing in the right direction. In this presentation you should cover the following aspects: 

  • What problem are you solving? (1 slide)
  • How did you divide the work between the team members? (1 slide)
  • What have you done so far? 
  • What are you going to do next and What are the challenges you are facing? (1 slide)
  • How do you plan to address them? (1 slide)

(the number of slides indicated in parentheses is just a guide; you can use more or fewer but plan to finish your presentation within 8 minutes max so that there is time for a couple of questions)

Final Presentation

Each project team will be given 12-minute final presentation (including demo). During your presentations, you will be warned at 10 minutes and you should stop by 12 minutes. It is recommended that the presentation slides should be no more than 7 slides. You should submit your final slides (via email to by Monday 27.03 at 9 am. You are allowed to make minor changes to your slides before your presentation day. However, you should inform course staff beforehand regarding changes. You can use your laptop to present your slides. 

In this presentation you should:

  • Explain the problem that you are solving (Recommended max. 1 slide)
  • Explain the division of work among team members (Recommended max. 1 slide)
  • Explain the system you have built. (Recommended max. 2 slides)
  • Explain the techniques you used to build the system. (Recommended max. 2 slides)
  • Show a brief demo (if feasible).

Deadline: Slides must be submitted (via email to Mss-staff@list.aalto.fiby Monday 27.03 at 9 am. If needed, a member of course staff will contact you to suggest changes. 

Final Report

Each project team must submit one final design report (4-6 pages), in which you describe the following:

Proposing Your Own Project

You are welcome to propose your own project topic. The proposed project can be on any system security topic, preferably covered in the course. You should write a description similar to those in the topic list, and send it to  as soon as possible, and discuss it with us (well before 2017-01-17). If your topic is approved by the course staff, you can proceed with it.

Responsibility of the adviser

Each project has an adviser, whose responsibilities are as follows:

  • propose topics and send them to before 2017-01-10
  • meet with project group members at least three times (but we encourage more frequent meetings)
    • after the topic is assigned to a group: explain the problem, provide background or related information, and provide an initial package of tools and documents.
    • before the mid-point presentation: check the progress and make sure that they are in the right direction.
    • before the final presentation: give guidance for the final presentation.
  • attend the final presentation.
  • provide feedback to course staff (  to help us evaluate the project.

List of Topics

Crawling forum posts and identification of reviewers with  multiple accounts


1 - Graphical user interface to SEALv2

SEAndroid [0] is an Android port of the well-established SELinux MAC mechanism [1] with some Android-specific additions and modifications. SEAndroid controls access to system resources at a kernel level, enforcing strict policy-based access control.

SEAL is a SEAndroid live device analysis tool [2, 7], which we have developed in the spring of 2015. It can perform policy analysis on Android devices (real or emulated) connected through ADB. More specifically, SEAL can query which processes on a device can access one specific file (or path), and conversely which files can be accessed by one specific process. SEAL is developed in Python.

SEALv1, released in June 2015 [3], also had a GUI (SEALX) which allowed the user to perform all the operations supported by the CLI program in a graphical context [4]. SEALX was implemented using the TkInter graphical toolkit. SEALv2, released in April 2016 [5], was converted to use setoolsv4 [6] and therefore broke compatibility with SEALv1. Due to time constraints, only the CLI version of the program was ported.

Your task will be to first get acquainted with SEAndroid, the SETools library [6] and the CLI version of SEALv2 [2]; second, you will implement a GUI for SEALv2 offering the same features as the CLI version. This GUI should be implemented in Python, using one of the newer graphical toolkits offered by the language (e.g. PyGObjects).

Basic understanding of access control and the Android security architecture.
Proficiency with the Python language. Familiarity with design of graphical interfaces is a plus.


2 - Online gambling using Ethereum

Ethereum [1]  is a decentralized platform that enables the execution of arbitrary applications (or contracts) on its blockchain. Owing to its support for a Turing-complete language, Ethereum offers an easy means for developers to deploy their distributed applications in the form of smart contracts. Ethereum additionally offers its own cryptocurrency Ether which is also used as the main fuel to execute the contracts and send transactions. Ether payments are commonly used to cover the costs related to contract execution; these costs are measured by the amount of gas they consume. 

The main task for this project is to develop an online Gambling game on top of Ethereum. Specifically, there are two players participate in this game and they are required to  puts some Ethers ahead of time. During the game, they jointly generate a random number. If it is an odd number, player one wins the game and get all the Ethers. Otherwise, player two win the game. This project has the following requirements:

  • The random number must be jointly generated by both players, i.e., neither of them can control the randomness.
  • Players cannot change their mind after knowing the result.
  • Players cannot run away without paying Ether after losing the game. 

Requirements: basic understanding of cryptography, knowledge of Ethereum development



3 - Android App for phishing detection

We developed a novel client-side technique for phishing detection relying on machine learning and feature extracted from the webpage content [1]. This system is already implemented as a proof of concept browser add-on for Firefox and Chrome [2] and is available for download [3]. This system is currently implemented in JavaScript and Python
The goal of this project is to implement the same system for Android to be used on mobile devices. It can either be implemented as a plug-in to an existing Android browser or as a full app taking as a basis an open-source Android browser and building the phishing detection system on top of it.

Requirements: Android and Javascript development. machine learning knowledge is a plus but not necessary.


4 - Crawling forum posts and identification of reviewers with multiple accounts

Doppelgängers are single entities who are controlling multiple accounts on online forums [1]. These might operate to promote a product or ideology, and some are bots. The task can be divided into roughly two parts: crawling forum poster profiles and forum posts, and identification of doppelgängers. The programmers is expected to crawl of profiles and forums posts and saving content to a local file, or preferrably a NoSQL database. One of online forums will be assigned to one group, these might: murobbs, helsingin sanomat comment sections, (a subset of) reddit comments. A working hull code for crawling websites with rabbitMQ and MongoDB is given as a starting point for development. More details will follow. The programmers are expected to extract suitable stylometric features from the crawled data. The programmers are expected to compare existing unsupervised stylometric tools to identify potential doppelgängers. More details will follow. This topic is cross-disciplinary is preferrably split between two persons.

Requirements: Basic understanding web scraping/crawling; Basic understanding of natural language processing techniques in machine learning (such as bag-of-words).

[1] Afroz, Sadia, et al. "Doppelgänger finder: Taking stylometry to the underground." 2014

5 - Identification of probabilistic fabricated reviews

Word-based markov chains (MCs) are simple language models, where the probability for generating a new character of dependent on previous characters. MCs have recently been used to generate Twitter comments in the US election (see TrumpBot [1], ObamaBot). One of the reasons Twitter is a suitable platform for MC-generated texts is the short Tweet length limits (140 characters). The higher the order of the Markov chain, the more like human-written language the model produces. As the sentence lengths become longer, the more clear the short event horizon becomes to a human reader. However, if trained on a too small corpus, the texts can become exactly identical to the the corpus sentences. We currently have generated 600 thousand Android play store reviews each in first, second and third order Markov chain, and have 600 thousand genuine (proposedly human-written) reviews from the store. The task is to compare existing (stylometric) techniques (links will follow) for authorship identification on the training set (half of the data) and compare the training set results to the test set (other half of the data). What kind of patterns do you notice, and what techniques are most appropriate?

Requirements: Basic understanding of natural language processing techniques in machine learning (such as bag-of-words).


6 - Secure implementations of one-time password schemes

One-time passwords are used to strengthen user authentication, often as second authentication factor. They require a user to enter a short single-use code at the time of authentication. The code is usually generated by a local application (e.g., on the user's smartphone) which shares a secret key with the authentication server. The shared secret key is agreed upon ahead of time between the server and the local application. Thereafter, whenever the user needs to authenticate to the server, he can ask the local application for the one-time code. Standard schemes for generating one-time codes include HOTP [1] and TOTP [2]. Usually the local application stores the shared secret key on its local storage, where it may be vulnerable to malware. One way to harden the security of such applications is to separate the security-sensitive parts of the application into a "trusted application" that can run within a trusted execution environment.

The objective of this project is to develop such a secure one-time password scheme using Open-TEE [3]. Background on trusted execution environments can be found in [5] and [6] as well as in Lecture 4 of the course.

Requirements: Familiarity with C/C++ programming, basic knowledge of cryptographic algorithms


7 - Cashless payments using NFC Cards and Android

At a party or similar large event, there may be many stands selling e.g. food and drinks, or other items. However, it is impractical for all of these stands to accept cash since not all of the guests carry small value cash with them. The vendors usually sell items that are of smaller values, e.g. few euros, it becomes inconvenient for the vendors to maintain enough cash changes as well as keep account of the item sold vs. collected cash. Also, the vendors are unlikely to accept payments via bank cards.

Ideally, we would like to use an efficient payment system where the guest can make an advance payment at the entrance or during registration in exchange for some tokens. They can later use the tokens to purchase items at the stalls and receive payments for the remaining tokens when they exist the event. Similarly, the vendors can afterward reconcile transactions with the event organizers to collect payment for the items they have sold for tokens.
One way to design such payment system is to use NFC technology where the event organizer distributes the NFC cards (e.g. DESFire cards) to the guest during registration. The NFC card would consist of a user account with pre-paid value on the cards in exchange for advance payments. The vendors would use an NFC application on their mobile phone to authenticate the card and deduct the amount equivalent to the item sold. The NFC application should also maintain a ledger to record the transactions. Afterward, the vendor should be able to clear the ledger with the event organizer to collect the payments.
The students are expected to 
- Understand the DESFire protocol.
- Understand accessing NFC card from Android phones using Android NFC APIs[2].
- Use Android App development environment (i.e., Android Studio) to create two separate apps: Admin App and Vendor App.
- The Admin App is intended to be used by the event organizers to create pre-paid account on the card
- The Vendor App is distributed to the vendors to deduct the amount from the card equivalent to the value of the item sold.


8 - Authentication for SGX enclaves in the cloud      

TH is well suited for stand-alone machines but its original design does not address the possibilities of introducing TH modules in a cloud. The main requirements of the cloud infrastructure include elasticity and scalability and they are satisfied by virtualization technologies [1]. While it is possible to provide a virtual machine (VM) with a virtual Trusted Platform Module, its operation in the cloud settings is still a challenge. In particular, the assumption that a particular TH is bound to a particular machine no longer holds when VMs should be migrated between different physical machines or when they should be replicated in order to meet service demand requirements. Migration and replication should ideally be transparent for the party that attests an enclave: it should not matter on what particular physical machine in the cloud the enclave is running as long as it is not tampered with. On the other hand, the cloud provider should be able to tell that a particular VM is actually running on its premises, i.e. it should be able to distinguish enclaves of VMs running on physical machines that belong to the provider from the ones that do not. Note that TH allows to tell what code is running inside the enclave but does not say anything about where it is running.

This assignment concerns writing an SGX [2] enclave that would allow cloud providers to attest that the virtual machine belongs to them. In particular, the enclave should contain a cloud provider key, then talking to it and acting as a man in the middle the cloud customer enclave can attest that it is running on the same machine thus that it is running on the machine that belongs to the given cloud provider. This is just one possible solution and you are free to come up with something else.

Requirements: C programming, basic understanding of Trusted Hardware architecture.


9 - Simple Software Architecture for ARM TrustZone-A

A Trusted Execution Environment (TEE) [1] is a secure, integrity-protected processing environment that is isolated from the "normal" processing environment of a device (often referred to as the Rich Execution Environment (REE)). Modern ARM Cortex-A processors enable a TEE and REE to co-exist on a single physical processor core by means of the TrustZone-A hardware security architecture [1]. TrustZone-A partitions hardware and software resources so that they exist in one of two worlds - the Secure world for the TEE, and the Normal world for everything else. Context switching between the two worlds is facilitated by a dedicated hardware interrupt, which puts the processor in Monitor mode. Software executing in Monitor mode saves the state of the current world and restores the state of the world being switched to and passes control to software to the restored world. The Monitor mode software, referred to as the Secure Monitor, acts as a robust gatekeeper which manages the switches between the Secure and Normal world. Its functionality is similar to a traditional operating system context switch. The Secure Monitor ensures that the processor state of the world the processors is leaving is safely saved, and that the state of the world the processor is entering is correctly restored.

The purpose of this programming project is to implement a simple software architecture for TrustZone-A in a ARMv7-A processor [2] including the Secure Monitor, Secure world, and Normal world software, all executing on bare-metal [3]. The target platform is the Raspberry Pi 2 Model B computer [4].

Requirements: Good software development skills in C, basic understanding of assembly programming, basic understanding of computer architecture and operating systems concepts.
(Note: for students with prior experience with bare-metal programming on Raspberry Pi computers and ARM assembly programming, this topic can be adapted to the ARMv8-A architecture using the Raspberry 3 as target platform)


10 - Android app Interface for BLE sensors

We have meta sensors communicating over Bluetooth Low Energy (BLE) [1]. The sensors provide measurements about motion, temperature, light, air pressure and humidity. An Android application having BLE communication rights can communicate with the sensors and read any sensor modality.  But we want to prevent all sensor’s data to be accessed without distinction.  

The goal of this project is to develop an Android application able to read/communicate with the BLE sensors and  to provide an interface for other applications to access the sensor’s data. The application must manage rights for each of the sensor modality (temperature, light, etc.) such that we are able to give fine grained access to other applications.

Requirements: Android programming


11 - Enhanced Android Keystore

When two users, Alice and Bob, want to send encrypted messages to each other, they first need to agree on a secret cryptographic key, which is only known to their devices. This can be done using any well-established key agreement protocol, such as authenticated Diffie Hellman (DH) key agreement. They also need to store this key securely on their devices. This could be achieved using the Android Keystore, which allows apps to generate, store, and use cryptographic keys securely. In some devices, the keystore can be "hardware-backed" such that its contents are protected by a Trusted Execution Environment (TEE), such as ARM TrustZone.

Since Android M (Android 6.0, API level 23), the Android keystore supports symmetric key operations (e.g. encryption, MAC), in addition to asymmetric key operations. However, it does not provide functionality for key-agreement, so in the above example Alice and Bob's new key is exposed outside the keystore during the key agreement protocol.

The aim of this project is to design and build an enhanced version of the Android Keystore that provides key agreement functionality. For example, the keystore can internally generate the secret values for the DH key agreement and then output the respective key agreement messages. Practically, this enhanced keystore can be developed and prototyped using Open-TEE, a virtual TEE for Android. This will involve some development in C for the software running inside the TEE and some Android development (e.g. an Android library to interact with keystore and demonstrate the key agreement functionality). The overall goal is to demonstrate two Android devices performing a key agreement directly between their keystores.

Requirements: Android and C development (familiarity with cryptographic protocols would be beneficial, but is not required)



12 - DDoS detection by machine learning

The development of protection methods against DDoS attack based on machine learning attracts many researchers because of its effectiveness and practical significance [1], [2]. Most commonly these detection methods use prelearned models or models based on rules. Because of this the proposed DDoS detection methods often failure in case of dynamically changing network traffic.
This project is devoted to the implementation of self-learning method allowing to adapt a detection model to the changes of network traffic. The method has to minimize the false detection and reduce the possibility to mark legitimate users as malicious and vice versa. You will be provided with the collected data about the network traffic by Cisco Netflow protocol [3]. The data include several scenarios of a temporary increase of the number of legitimate requests to web servers and the number of the web servers under DDoS attack. The scenarios could be separated from one another.
At first, you have to implement the detection model using machine learning. The detection model has to detect DDoS attacks and legitimate traffic at least one scenario with F1 score ≥ 0.9.
In the second, it is expected that you will find a point when the detection model needs to be relearn. Based on this you can implement the relearn process automatically. The mean F1 score for all traffic must be more or equal 0.9. As a tool for machine learning you can use scikit-learn [4] software.

Requirements: Basic understanding of machine learning, Python.

[1] K. Borisenko, A. Rukavitsyn, A. Gurtov, A. Shorov. Detecting the Origin of DDoS Attacks in OpenStack Cloud Platform Using Data Mining Techniques. Internet of Things, Smart Spaces, and Next Generation Networks and Systems, 2016, vol. 9870, pp.303-315.
[2] R. Karimazad, A. Faraahi. An anomaly-based method for DDoS attacks detection using RBF neural networks. [Proc. of the International Conference on Network and Electronics Engineering, Singapore], IACSIT Press, 2011, pp. 44–48.


  • No labels