Archívum - 2016-2017-2

Archive - 2016-2017-2


Biztonsági protokollok (VIHIMA05)

A tárgy az IT biztonság MSc mérnök-informatikus mellékspecializáció keretén belül kerül előadásra a tavaszi félévben. A hivatalos tantárgyi adatlap és tárgykövetelmények a kar szerverén találhatók. Erről az oldalról a tárggyal kapcsolatos legfrisseb adminisztratív információkat, az előadások anyagát, és egyéb fontos tudnivalókat lehet letölteni illetve elérni. Ennek megfelelően ez az oldal folyamatos frissítés alatt áll.

Korábbi évek weblapjai: 2015, 2016

Célkitűzés

Objectives

A tárgy célja, hogy (i) megismertesse a hallgatókkal a modern vezetékes és vezeték nélküli hálózatokban felmerülő, a hálózati kommunikáció biztonságával kapcsolatos problémákat, (ii) bemutassa a biztonsági problémák megoldására használt korszerű biztonsági protokollok elveit és gyakorlati megvalósításait, és (iii) az ismertetett protokollok részletes analízisén keresztül betekintést nyújtson a biztonsági protokollok tervezési kérdéseibe.

Lecturers

Előadók

Követelmények

Requirements

A szorgalmi időszakban

2 db házi feladat és 1 db nagy zárthelyi dolgozat.

Opcionális pontok

Az órák végén kiugrót iratunk, melyben kontroll kérdéseket teszünk fel az órán elhangzott anyaggal kapcsolatban. Ennek célja, hogy feedback-et kapjunk az órák hatékonyságáról. A kiugró nem ZH, nem kötelező megírni, és kizárólag pozitív irányban befolyásolhatja a félévvégi jegyet. Konkrétan, minden kiugró eredménye bináris: 5-ből 3 kérdés helyes megválaszolása 1 pontot ér, egyébként 0 pont jár. Az így szerzett extra pontok beszámítanak a félév végi eredménybe.

A félévvégi érdemjegy számítása

P = ZH + HF1 + HF2 + E, ahol ZH a zárthelyi dolgozatra kapott pontszám (min 30, max 60 pont), HF1 és HF2 a házi feladatokra kapott pontok (házinként min 10, max 20 pont), E a kiugrókon szerzett extra pontok száma. Ponthatárok: jeles: P >= 85 pont; jó: P >= 70 pont; közepes: P >= 55 pont; elégséges: P >= 40 pont; elégtelen: P < 40 pont.

Órák ideje és helye

Time and location of classes

Előadás

Lecture

  • kedd, 10:15-12:00, IB.147
  • péntek, 10:15-12:00 (csak páros heteken), QBF.08

Gyakorlat

Practise

  • Nincs külön időpontokban a gyakorlat, a gyakorlat jellegű részek be vannak építve az előadásokba.

Konzultáció

Megbeszélés szerint, az előadóval előre egyeztetett időpontban.

Office hours

Please contact the lecturer to schedule an appointment.

Előadások

Lectures

Dátum Téma Előadó
Date Topic Lecturer
2017.02.07. A kriptográfia története Buttyán L.
2017.02.14. Kulcsfolyam-rejtjelezők Buttyán L.
2017.02.17. Blokkrejtjelezők Buttyán L.
2017.02.21. A CBC mód elleni támadások Buttyán L.
2017.02.28. Hash függvények és üzenethitelesítő kódok Buttyán L.
2017.03.03. A biztonságos csatorna absztrakció Buttyán L.
2017.03.07. Publikus kulcsú algoritmusok Buttyán L.
2017.03.14. Kulcscsere protokollok I Buttyán L.
2017.03.17. Kulcscsere protokollok II Buttyán L.
2017.03.21. --- ELMARAD ---
2017.03.28. Véletlenszám generálás Buttyán L.
2017.03.31. WiFi biztonsági protokollok Buttyán L.
2017.04.04. Transport Layer Security I Buttyán L.
2017.04.11. Transport Layer Security II Buttyán L.
2017.04.14. --- ELMARAD (NAGY PÉNTEK) ---
2017.04.18. Protokollok erőforrás korlátozott környezetben Buttyán L.
2017.04.25. Anonim kommunikáció, Jelszó alapú kulcscsere Buttyán L.
2017.04.28. Publikus kulcs infrastruktúra Endrődi Csilla (Microsec)
2017.05.02. Nagy házi bemutatása Buttyán L.
2017.05.09. Nagy ZH
2017.05.12. Pót ZH

Házi feladat

Homework

1. házi feladat

The goal of the semester project is to use the cryptographic building blocks that we learned during the lectures in practice. We believe that a learning-by-doing approach leads to deeper understanding of the subject.
To make it fun and somewhat less of an effort, the semester project can be carried out in groups of 2-3 students. This also allows students to gain experience in team work and collaborative development of software. So, please, team up with your buddies, and send me (buttyan@crysys.hu) the names of your group members!
The theme of the semester project is the development of a secure, multi-party, on-line chat application. The project has two phases: (1) in the first phase, teams have to come up with a design and submit a sufficiently detailed description (that looks like an engineering document) of their envisioned cryptographic protocols for verification, and (2) in the second phase, after receiving some feedback on the design, teams have to implement their (potentially corrected) designs using a real crypto library.
We will prepare and distribute a sample chat application (source code in Python for the chat server and chat clients), which will implement the basic communication primitives (sending and receiving chat messages) and some management functions (logging into the chat server, creating a new conversation, listing ongoing conversations, and joining an active conversation). The sample application will be fully functional, but it won't contain any cryptographic protection of chat messages. The task will be to extend this application with security features (setting up cryptographic keys among the chat participants, and applying encryption and integrity protection mechanisms on chat messages). Extending the sample application allows teams to focus on the crypto part, rather than spending time on the chat primitives themsleves. Nevertheless, if you want to start from scratch (e.g., because you want to implement your project in another programming language, or simly because you don't want to spend time on understanding the code written by someone else), then we will not stop you doing that!

In the first (design) phase of the project, you do not really need the sample application. You can think of it as a standard client-server application, and you can assume that primitives are available for managing conversations and sending textual messages. It is important, however, that all communications should be mediated by the server, so chat clients cannot talk directly to each other. Teams should design protocols for setting up keys among the chat participants, such that the server should not have access to those keys (i.e., we assume that the server is an 'honest but curious' party, which we trust for managing user accounts and chat conversations, but we don't trust it for accessing the content of those conversations - pretty much like the trust we should have in a cloud service provider in real life). Teams should also design protection mechanisms for chat messages to prevent eavesdropping and to detect replay or modification of messages, as well as injection of fake messages by the server. Designs should follow the design principles that we have learned in the classroom. Teams should produce a document that contains the description of their design in sufficient details, and submit that document here (choose 'VIHIMA05 - Design') by the deadline given below.

Deadlines

Határidő

2017. 03. 27. (midnight)

2. házi feladat

In the second (implementation) phase, teams will implement their design (after feedback and potential corrections). Those relying on the sample chat application provided should use the PyCrypto crypto library. The sample application will implement an API to send and recieve strings to and from the server within the context of an ongoing conversation managed by the server. The server will forward a received string to all other participants of the conversation. Your implementation should use these primitives to carry your protocol messages. This means that your protocol messages should be encoded by the sender chat participant as a string, and parsed and processed by the receiving chat participants. Depending on the message type, receiving chat participants should then either respond with an appropriate protocol message, or display the decoded chat messages to the user. Implementations should keep track of protocol states and handle errors. Teams should complete and submit their work (source files in a zip file) here (choose 'VIHIMA05 - Implementation') by the deadline below. All teams will run a demo in the classroom on May 2. We will look into the source code to check if teams carefully implemented their designs.

Deadlines

Határidő

2017.05.01. (midnight)

Számonkérés

Exam

  • ZH: 2017.05.09. - ZH eredmények
  • Pót ZH: 2017.05.12. - óra idejében és helyén
  • Pótpót ZH: tbd - tbd

Kiegészítő források

Readings