This class focus on the theory and practice of secure embedded/IoT system.
Students will be exploring security and privacy issues in deployed or emerging IoT systems, examining a rich
variety of devices from drones and self-driving cars to smart home light bulbs and implanted pacemakers, across
different layers of computing from network to wireless signal, from application to device kernel and driver.
This class is organized with a set of pre-selected topics, with lecture and discussion on those topics. It is a
project oriented class, where each student or teams of student will pick a topic of their interest within the
scope of the class, then develop a project to a real world security issue on IoT/embedded system.
- Solid programming skill, Basic Networking and OS concepts (CSE 361S,422S,433S,473S,523S)
- Feel free to join the class without pre-req as long as you are willing to pick up the system knowledge in
the first several weeks of the class.
There is no textbook for the class. We will use research papers for some of the topics. However, the following
references can be helpful.
- Embedded Systems Security: Practical Methods for Safe and Secure Software and Systems Development
- Understanding the Linux Kernel, Third Edition
- A Guide to Kernel Exploitation: Attacking the Core
This assignment has two parts
- Write one blog entry on the topic last lecture
- Lead the discussion for 10 mins on the next class on this particular topic
If you need a suggestion, the topic can be one of the following
- Recently disclosed vulnerability and demo
- Recent incident in the news - you need to present the root cause, discussion and potential solution
- A broader overview of the topic from last week
- A related but not covered topic from last week
- Demo of a new security tool
Log and lightning talk signup is here
Our class blog is here
Format:The class project will be carried out by a team of 2 - 4 students,
and is divided into four rounds with the last found being the final project.
We will have demo/presentation after each round.
Project Scenario: On a sunny Saturday morning, you are sitting in your backyard in University City thinking about your strategies for the new startup on billion-dollar business of IoT. And you realize IoT really are nothing but decade-old sensors connected via mesh network without the intelligence behind. To be successful, you need to be able to understand your customer's preference and correctly predict that they actually want to have lasagna instead of fried rice such that you can put up the right suggestion of restaurants for them tonight and collect the referral fees. To gain that intelligence, you need computation power, lots of them, but then you are a startup that can't afford significant up front investment on just the infrastructure, so you decided to turn to the Cloud - the platform that solves all the problems. Our story begins here...
Develop an AI/ML module of your choice that will perform the following. You could use our skeleton
or not. However, no question will be answered regarding any code or internal design decisions of the skeleton. In the real world, you often won't have answers to code you borrow from other projects.
- Process sensitive data which is given to you in AES encrypted format.
- Your module has to decrypt those data, perform some processing to train the model.
- The trained model should be saved to disk using a randomly generated secret key.
- You have to write the random number generator yourself instead of using /dev/urandom.
- The module should support user management - set password, change password, and login.
- The module should also support an interface to accept sample data and return the prediction result.
- both user data and model are considered sensitive and should be not accessible by the attacker.
- You are required to have at least three exploitable vulnerability in your code base, insert them at places
that is difficult for your opponents to discover them, these vulnerability can be - buffer overflow, integer overflow, type confusion, format string vulnerability, misused of cryptographic cryptography. Please indicate the bugs in your submitted write up.
- You are not allowed to change the compilation options in the skeleton.
- Notes: It is recommended that your AI/ML module to be standalone c files with few dependencies
The provided skeleton contain four main components:
- main function - contains the CLI of the program
- crypto - contains cryptographic functions such as encryption and key generation
- access control - contains user account control
- ml - contains the functionality to train and use a model
You are encouraged to modify the provide skeleton code to fit the goal of your startup. If you consider the provided skeleton perfectly secure, you can keep everything.
For AI/ML modules, kmeans is used in the provided example. It is recommended that you choose a different AI/ML module, i.e. either libSVM or CNN.
You are welcome to use AI/ML modules of your own choice. However, keep in mind that if you choose to do so, TA might not be able to help you with porting it to the provided framework. Moreover, you are responsible for providing the training and testing datasets, their descriptions, and detailed documentation on how to run it.
Demo should show
- The procedure to use your module
- The basic functionality of your new ML module
- The unit test should still work
- The added features if there are any
Submission should contain
- Complete instruction to verify the functionality your project - for example, running the unit test
- The complete source code
- documentation of the list of bugs you've identified and fixed in discovered_vulnerability.md - the write up should describe why this is a vulnerability and how it can be exploited
- documentation of the three exploitable vulnerability you inserted into the program in vulnerability.md - the write up should describe why this is a vulnerability and how it can be exploited
- clear documentation of individual contributions among the team members
Evaluation: There are two parts of evaluation in this step:
- 10 pt - Functionality - how well did the developed system meet the requirement.
- 5 pt - Documentation - does the document describe the necessary minimum steps to use the system including
the test and evaluation dataset.
Attack your opponent's software - your goal to violate any of the security assumption in the first round. You can assume you have program running on the same Linux machine of the target, but you may need to deploy different tactics according to your privilege levels. This includes but not limited to the following
- Able to decrypt the AES encrypted data without access to the original encryption key (find ways to get
access to it :-D )
- Able to perform arbitrary code execution on the target program
- Able to steal the classification model
- Able to influence the classification accuracy
- Able to login to user account other than the one that's originally setup
- Anything else you can think of to violate the assumption
There are three types scenario you should be launching the attack, with increasing difficulty. Assuming you have
- OS privilege
- Root privilege but no access to kernel
- Others privilege
20 pt - Able to demonstrate attack at any of three privilege levels - present at least three attacks, grading will be based on the novelty of the attack as well as the discovered attack vectors. You need to submit the following
For extra credit
- Exploit.md that describes your method of exploitation (design, implementation, use) - if you find more, please indicate your personal favorite three
- Exploit code
For each vulnerability you submit, there should be proof of concept (PoC) attack code as well as procedure to go with it. Up till 9/24, vulnerability you found on your opponent team belongs to you. However, after 9/24, you can work on any team and it is based on the order of discovery. You can find the current list of disclosed vulnerability here
To submit a vulnerability, send your docmentation, PoC source code in an email to TA and cc me, with CSE 569S VD - "name" - "PoC name" in the title. TA will attempt to keep the spreadsheet updated daily. There could be a maximum delay of two days. Let the instructor know if there is any significant delay on your submission.
- 12 pt (Extra credit) - Able to demonstrate additional attack. You can participate in this as individual or team. If you particpate as a team, your score will be evenly divided among the team member. The score you got for each vulnerability discovered will be given based on novelty of the attack. For example, achieving remote code execution is better than deny of service. Exploiting an oversight in random number generation is better than a plain buffer overflow. The higher your score is, the more extra credit you will get.
- 3 pt (Extra credit) - The team will less vulnerability found against them will be given extra credit.
Build your defense against the previous round of attack using TEE
You are also required to mitigate all the attacks discovered in the previous round
Evaluation will consist of two parts:
- 10 pt - TCB Minimization - the design of the TEE migration
- 5 pt - Defense - able to defend against all previous round attacks
The final project is an open ended project, where students are encourage to take on challenging project ideas
by expanding on the previous rounds, this can be
- use TEE to protect other real-life applications -
ML [ Code and Data ],
- apply new techniques to attack applications inside TEE
- apply new techniques to attack TEE
- prototype one of the cyber-physical attacks
Your grade will be evaluated by the novelty of the attack or defense(can be a failure), and the steps you took towards the goal. This project has to be a group project. There is no limitation on the size of the group, though groups with 3 - 5 students are often most effective. There are three checkpoints of the project
- 5 pt - Proposal - it should include
1) description of the project - what you intend to work on,
2) individual responsibilities - the proposal should include responsibility of individual member,
3) Deliverables of project - the expected product in checkpoint and final demo,
4) Steps - high level items for each week towards the goal.
- 5 pt - Project Checkpoint - at checkpoint, teams should have a prototype, and re-base the schedule and goal
- 15 pt - Final Writeup and Demo - this would include final demo, write up, source code and documentation
Please note that reproducibility will be a key evaluation criteria, make sure all the submitted materials are clearly documented.