System Security


  • Course: System Security (MCSSE-CYB-02)
  • Semester: Spring 2024
  • Prerequisites: Cryptography (MCSSE-CYB-01)
  • Instructor: Jürgen Schönwälder
  • Office Hours: Monday, 11:15-12:30, R.1-87
  • Class: Wednesday, 14:15-15:30, RLH Seminar Room
  • Class: Friday, 15:45-17:00, RLH Seminar Room
  • 1st Module Exam: Tuesday, 2024-05-28 12:30-14:30 (East Hall 6)
  • 2nd Module Exam: Thursday, 2024-08-29 11:00-13:00 (East Hall 4)

Content and Educational Aims

This module focuses on system level security aspects of computing systems. The module starts with investigating attacks on the microarchitecture of computing systems, such as attacks to gain information from side channels targeting caches. It then introduces trusted execution environments that use hardware isolation mechanisms to provide protected storage for keys and to bootstrap the integrity of bootloaders and the loaded operating systems. Students learn about the different levels of isolation that can be achieved using various types of hypervisors or sandboxing mechanisms. Techniques that can be used to protect a system against misbehaving code and malware are introduced. Students will gain knowledge how protected data storage components can be provided at the system level and how systems can offer support for collections of (distributed) authentication mechanisms. Finally, the module will discusses how authorization mechanisms are realized in the different system software components and how they can be used to define effective security policies.

Intended Learning Outcomes

Upon completion of this module, students will be able to

  1. describe microarchitectural attacks on computer components and suitable counter measures
  2. illustrate trusted execution environments and how they can be used to bootstrap security
  3. compare the isolation achieved by hypervisors and operating system mechanisms
  4. assess application layer isolation and sandboxing mechanisms
  5. explain how systems can identify misbehaving code and protect themselves against malware
  6. outline how protected data storage can be implemented
  7. recommend authentication methods suitable for different kinds of applications
  8. compose authorization mechanisms to define effective security policies


  • William Stallings, Lawrie Brown: Computer Security: Principles and Practice, 4th edition, Pearson, 2018
  • Swarup Bhunia: Hardware Security: A Hands-on Learning Approach, Morgan Kaufmann, 2018


Wed 14:15 Fri 15:45 Topics
2024-02-02 Introduction to System Security
2024-02-07 2024-02-09 Attacks on Hardware (Side Channels, Fault Injection, Microarchitectural Attacks)
2024-02-14 2024-02-16 Attacks on Software (Control Flow Attacks, Code Injection, Data Races)
2024-02-21 2024-02-23 Specific Attacks on Hypervisors and Operating System Kernels
2024-02-28 2024-03-01 Specific Attacks on Systems Software and Applications
2024-03-06 2024-03-08 Security by Design, Control Flow Integrity
2024-03-13 2024-03-15 Control Flow Integrity
2024-03-20 2024-03-22 Isolation
2024-03-27 2024-03-29 [Spring Break]
2024-04-03 2024-04-05 Linux Security Modules
2024-04-10 2024-04-12 Sandboxes and Privilege Separation
2024-04-17 2024-04-19 Container Security, Linux Namespaces
2024-04-24 2024-04-26 Trusted Computing, Remote Attestation
2024-05-01 2024-05-03 Trusted Execution Environments, Condidential Computing
2024-05-08 2024-05-10 Malware Analysis and Detection
2024-05-15 2024-05-17 Security Incident Detection and Response


Date/Due Name Topics
2024-03-11 Sheet 01 software vulnerabilities
2024-03-25 Sheet 02 control flow integrity
2024-04-15 Sheet 03 mandatory access control, secure computing bpf


The final grade is determined by a final exam (100%). There will be bi-weekly marked homework assignments.

Electronic submission is the preferred way to hand in homework solutions. Please submit documents (plain ASCII/UTF-8 text or PDF, no Word) and your source code (packed into a zip archive after removing all binaries and temporary files) via the online submission system. If you have problems, please contact one of the TAs. Solutions for assignments may need to be defended in an oral interview.

Late submissions will not be accepted. In case you are ill, you have to follow the procedures defined in the university policies to obtain an official excuse. If you obtain an excuse, the new deadline will be calculated as follows:

  1. Determine the number of days you were excused until the deadline day, not counting excused weekend days.
  2. Determine the day of the end of your excuse and add the number of day you obtained in first step. This gives you the initial new deadline.
  3. If the period between the end of your excuse and the new deadline calculated in the second step includes weekend days, add them as well to the new deadline. (Iterate this step if necessary.)

For any questions stated on assignment sheets, quiz sheets, exam sheets or during makeups, we by default expect a reasoning for the answer given, unless explicitly stated otherwise.

Students must submit individual solutions. If you copy material verbatim from the Internet or other sources, you have to provide a proper reference. If we find your solution text on the Internet without a proper reference, you risk to lose your points. Any cheating cases will be reported to the registrar. In addition, you will lose the points (of course). These rules also apply to any generative AI tool, such as ChatGPT.

  1. You are discouraged from using AI tools UNLESS under direct instruction from your instructor to do so.
  2. If AI is permitted to be used, you must clearly state how AI was used in completing the assignments. No more than 25% of an assignment should be created with AI if the instructor gives permission for its use.
  3. Note that the material generated by these programs may be inaccurate, incomplete, or otherwise problematic. Their use may also stifle your own independent thinking and creativity. Accordingly, reduction in the grade is likely when using AI. Rather use your own brain.

Any programs, which have to be written, will be evaluated based on the following criteria:

  • correctness including proper handling of error conditions
  • proper use of programming language constructs
  • clarity of the program organization and design
  • readability of the source code and any output produced

Source code must be accompanied by a README file providing an overview of the source files and giving instructions how to build the programs. A suitable Makefile is required if the build process involves more than a single source file.

If any part of these rules are confusing or uncertain, please reach out to your instructor for a conversation before submitting your work.

If you are unhappy with the grading, please report immediately (within one week) to the TAs. If you can't resolve things, contact the instructor. Problem reports which come late, that is after the one-week period, are not considered anymore.