Заштита података/Јун 2023

Ispit u junskom roku 2023. održan je 16. juna. Održan je u dva termina (jedan SI, jedan RTI). Na RTI bilo je dostupno okruženje PyCharm kao i dokumentacija za Python. Ispit na RTI trajao je 90 minuta, a na SI sat vremena.

SI G1

1. zadatak

Koji od navedenih kriptografskih algoritama će moći da se koriste i nakon široke dostupnosti kvantnih računara?

1. RSA
2. DSS
3. XMSS - extended Merkle Signature Scheme
4. Lamport Diffie
5. Diffie-Hellman
6. AES
7. SPHINCS+

2. zadatak

Овај задатак није решен. Помозите SI Wiki тако што ћете га решити.

Potrebno je obezbediti zaštitu transfera veb sadržaja između veb servera A i veb klijenta B koji se nalaze povezani na internet. Ono što je neophodno obezbediti je da strana koja prima poruke u svakom trenutku bude sigurna da podatke koji se prenose niko nije promenio niti pročitao tokom prenosa, kao i sa koje tačno IP adrese su paketi došli. Pri tome potrebno je obezbediti minimalno opterećenje, kako procesora, tako i mrežne veze veb servera. Protokol koji zadovoljava sve prethodno postavljene kriterijume je:

1. AH u transportnom režimu rada
2. ESP u tunel režimu rada
3. IKE
4. TLS
5. AH u tunel režimu rada
6. QUIC
7. ESP u transportnom režimu rada

3. zadatak

Na slici je dat prvi deo Kerberos v4 autentikacije:

• $(1) \quad \mathbf{C \rightarrow AS} \quad ID_c \parallel ID_{tgs} \parallel TS_1$
• $(2) \quad \mathbf{AS \rightarrow C} \quad E\left( K_c, \left[ \qquad \parallel TS_2 \parallel Lifetime_2 \parallel Ticket_{tgs} \right] \right)$
• $\qquad Ticket_{tgs} = E\left( K_{tgs}, \left[ \qquad \parallel TS_2 \parallel Lifetime_2 \right] \right)$

Elementi koji nedostaju u Ticket_tgs (ne i u poruci (2)) su:

1. identifikator servera AS
2. identifikator TGS
3. identifikator klijenta C
4. IP adresa servera V
5. IP adresa klijenta C
6. IP adresa servera AS
7. ključ kojim komuniciraju klijent i autentikacioni server AS
8. ključ kojim komuniciraju klijent i server V
9. identifikator servera V
10. ključ kojim komuniciraju klijent i TGS

4. zadatak

U AMD SEV lancu sertifikata par ključeva koji je jedinstven za svaki čip je:

1. PEK
2. ASK
3. ARK
4. CEK
5. PDH
6. OCA

Objašnjenje: Ovaj ključ, zvani Chip Endorsement Key, pravi proizvođač čipa (AMD) i potpisuje svojim ključem (ASK).

5. zadatak

Овај задатак није решен. Помозите SI Wiki тако што ћете га решити.

Ključ(evi) koji se slučajno generišu u AMD SEV sigurnoj komunikaciji između klijenta i servera je/su:

1. TEK
2. TIK
3. KEK
4. KIK
5. VEK

6. zadatak

1. Nikola je primetio da i kada ugasi pretraživač i mejl servis, količina saobraćaja prema njegovom računaru ostaje izraženo povišena. Radi se o tipu malicioznog softvera koji se naziva flooder.
2. Tip propusta koji se nalazi u sledećem kodu naziva se zadnja vrata.

if password = "aUtH h4ck3r" then login = USER_OK
else if correct_login(user, password) then login = USER_OK
else login = USER_FAILED
if login == USER_OK then login()

7. zadatak

Šta se sve nalazi u strukturi RecipientInfo prilikom slanja S/MIME poruke tipa obmotani podaci? Ukoliko se broj primalaca poveća, da li se i kako menja broj ovih struktura? Obrazložiti.

Odgovor:

Blok o primaocu sadrži sledeće podatke:

• identifikator sertifikata javnog ključa primaoca,
• identifikatori algoritama korišćenih da se šifruje ključ sesije i sadržaj poruke, i
• šifrovani ključ sesije.

Ukoliko se broj primalaca poveća, potrebno je dodati još ovih blokova, jer svaki primalac ima različit javni ključ pa se sa svakim uspostavlja različit ključ sesije.

8. zadatak

Sledeći algoritmi omogućavaju dobijanje različitih kriptografskih ključeva u svakoj TLS razmeni i to takvih da je moguća verifikacija porekla ključeva.

1. RSA
2. Ephemeral Diffie Hellman
3. Anonymous Diffie Hellman
4. Fixed Diffie Hellman

Ovom porukom se predlažu kriptografski algoritmi koji će biti korišćeni u toku TLS sesije:

1. Server Hello
2. Server Hello Done
3. Client Hello Done
4. Certificate Verify
5. Certificate Request
6. Finished
7. Client Key Exchange
8. Client Hello
9. Change Cipher Specification

9. zadatak

Prikazano je zaglavlje jednog bloka transakcija na bitcoin blokčejnu. Ako prikazani hash odslikava zahtevanu težinu problema potvrde bloka, koliko je prosečno potrebno različitih Nonce vrednosti da bude isprobano dok se ne dobije odgovarajuća potvrda transakcije? Smatrati da je raspodela hash funkcije uniformna. Odgovor dati u obliku 2^n.

• Number Of Transactions: 1502
• Transaction Volume: 316.33241479 BTC
• Transaction Fees: 0.06640796 BTC
• Height: 685698
• Time: 2021-05-31 22:38:48
• Bits: 386752379
• Size: 896,885(bytes)
• Version: 536870916
• Nonce: 432023578
• Block Reward: 6.25 BTC
• Days Destroyed: 6,678
• Hash: 000000000000000000027e3d890d8487f45f409c6b9e3a1321a82577f00d5126

Odgovor: 2^78

Objašnjenje: Videti objašnjenje za deveti zadatak iz G2.

SI G2

1. zadatak

Koji od navedenih algoritama mogu da daju ispravne digitalne potpise koji mogu da imaju različite vrednosti za istu poruku potpisanu istim ključem?

1. Lamport Diffie
2. DSS
3. ElGamal
4. Winternitz
5. RSA PSS

2. zadatak

Potrebno je obezbediti zaštitu transfera veb sadržaja između veb servera A i veb klijenta B koji se nalaze povezani na internet. Ono što je neophodno obezbediti je da strana koja prima poruke u svakom trenutku bude sigurna da podatke koji se prenose niko nije promenio tokom prenosa, kao i sa koje tačno IP adrese su paketi došli. Pri tome potrebno je obezbediti minimalno opterećenje, kako procesora, tako i mrežne veze veb servera. Protokol koji zadovoljava sve prethodno postavljene kriterijume je:

1. AH u transportnom režimu rada
2. ESP u tunel režimu rada
3. IKE
4. TLS
5. AH u tunel režimu rada
6. QUIC
7. ESP u transportnom režimu rada

Objašnjenje: Authentication Header nam obezbeđuje samo autentičnost podataka, što je nama ovde potrebno, kao i zaštitu nepromenljivih polja IP zaglavlja (iako je na snimcima predavanja možda rečeno da se IP adrese mogu menjati, ovaj odgovor je bio označen kao tačan). Kako se podaci prenose između jednog servera i klijenta, i kako je potrebno obezbediti minimalno opterećenje, dovoljno je da u ovom slučaju koristimo transportni režim rada.

3. zadatak

• $(1) \quad \mathbf{C \rightarrow AS} \quad ID_c \parallel ID_{tgs} \parallel TS_1$
• $(2) \quad \mathbf{AS \rightarrow C} \quad E\left( K_c, \left[ K_{c,tgs} \parallel ID_{tgs} \parallel TS_2 \parallel Lifetime_2 \parallel Ticket_{tgs} \right] \right)$
• $\qquad Ticket_{tgs} = E\left( K_{tgs}, \left[ K_{c,tgs} \parallel ID_c \parallel AD_c \parallel ID_{tgs} \parallel TS_2 \parallel Lifetime_2 \right] \right)$
• $(3) \quad \mathbf{C \rightarrow TGS} \quad ID_v \parallel Ticket_{tgs} \parallel Authenticator_c$
• $(4) \quad \mathbf{TGS \rightarrow C} \quad E\left(K_{c,tgs}, \left[ K_{c,v} \parallel ID_v \parallel TS_4 \parallel Ticket_v \right]\right)$
• $\qquad Ticket_{tgs} = E\left( K_{tgs}, \left[ K_{c,tgs} \parallel ID_c \parallel AD_c \parallel ID_{tgs} \parallel TS_2 \parallel Lifetime_2 \right] \right)$
• $\qquad Ticket_v = E\left( K_v, \left[ K_{c,v} \parallel ID_c \parallel AD_c \parallel ID_v \parallel TS_4 \parallel Lifetime_4 \right] \right)$
• $\qquad Authenticator_c = E\left(K_{c,tgs}, \left[ ID_c \parallel AD_c \parallel TS_3 \right]\right)$
• $(5) \quad \mathbf{C \rightarrow V} \quad Ticket_v \parallel Authenticator_c$
• $(6) \quad \mathbf{V \rightarrow C} \quad E\left(K_{c,v}, \left[TS_5 + 1\right]\right) \text{(for mutual authentication)}$
• $\qquad Ticket_v = E\left( K_v, \left[ K_{c,v} \parallel ID_c \parallel AD_c \parallel ID_v \parallel TS_4 \parallel Lifetime_4 \right] \right)$
• $\qquad Authenticator_c = E\left(K_{c,v}, \left[ ID_c \parallel AD_c \parallel TS_5 \right]\right)$

Na slici je data Kerberos v4 autentikacija. Sledeći stavovi su tačni:

1. Vreme $TS_3$ služi za to da spreči Replay napad tokom vremena trajanja tiketa $Ticket_{tgs}$
2. Vreme $TS_4$ služi za to da spreči Replay napad tokom vremena trajanja tiketa $Ticket_{tgs}$
3. Vreme $TS_5$ služi za to da spreči Replay napad tokom vremena trajanja tiketa $Ticket_{tgs}$
4. Ključ $K_{tgs}$ je javni ključ TGS
5. Ključ $K_{tgs}$ je privatni ključ TGS
6. Ključ $K_{tgs}$ je ključ TGS koji dele TGS i AS
7. $Lifetime_2 < Lifetime_4$
8. $Lifetime_2 = Lifetime_4$
9. $Lifetime_2 > Lifetime_4$

Objašnjenje: $TS_3$ sprečava napadača da ponovi poruku 3 kako bi obnovio $Ticket_v$ dok traje $Ticket_{tgs}$. Ključ $K_{tgs}$ ne može biti privatni ključ TGS jer ga mora posedovati i AS, a kako Kerberos koristi samo simetričnu enkripciju znači da nisu uključeni javni i privatni ključevi u komunikaciji. $Lifetime_2$ mora biti duži od $Lifetime_4$ kako bi klijent mogao više puta da obnovi $Ticket_v$ tokom trajanja $Ticket_{tgs}$.

4. zadatak

U AMD SEV lancu sertifikata par ključeva koji je jedini dvostruko potpisan je:

1. PEK
2. ASK
3. ARK
4. CEK
5. PDH
6. OCA

Objašnjenje: Ovaj ključ je potpisan od strane OCA (ključ vlasnika platforme) i CEK (ključ proizvođača čipa).

5. zadatak

Ključ(evi) koji se ne koristi/koriste u AMD SEV sigurnoj komunikaciji između klijenta i servera je/su:

1. TIK
2. KIK
3. KEK
4. TEK
5. VEK

6. zadatak

1. Marko je pronašao novu interesantnu igricu za svoj telefon. Pretražujući internet, Marko je pronašao sajt sa kojeg može da preuzme igricu besplatno. Kada je Marko preuzeo i instalirao igricu, aplikacija je od Marka tražila dozvolu za korišćenje nekoliko funkcionalnosti telefona. Neke od traženih dozvola su: "Pristup kontaktima telefona" i "Slanje SMS poruka". Kojim tipom malvera je zaražena igrica? spamer
2. Koji tip malvera predstavlja sledeći fragment koda? logička bomba

if datum is Friday the 13th:
    crash_computer();

7. zadatak

Sledeći algoritmi ne omogućavaju verifikaciju porekla ključeva.

1. Anonymous Diffie Hellman
2. RSA
3. Ephemeral Diffie Hellman
4. Fixed Diffie Hellman

Objašnjenje: Anonymous Diffie Hellman je osnovna varijanta Diffie-Hellman algoritma gde obe strane nemaju način da verifikuju javne ključeve druge strane pa je zato podložna man-in-the-middle napadu.

Ovom porukom se potvrđuju kriptografski algoritmi koji će biti korišćeni u toku TLS sesije:

1. Client Hello Done
2. Certificate Request
3. Change Cipher Specification
4. Server Hello
5. Finished
6. Server Hello Done
7. Client Hello
8. Certificate Verify
9. Client Key Exchange

Objašnjenje: Kada klijent uspostavlja komunikaciju, u svojoj Client Hello poruci šalje predloge algoritama za korišćenje u sesiji, dok server te algoritme potvrđuje svojom prvom porukom odgoovra, odnosno Server Hello.

8. zadatak

Kada formiramo SMIME potpisane podatke, šta sve treba da sadrži blok o pošiljaocu (signer info)? Da li broj ovih blokova zavisi od broja primalaca ili ne? Obrazložiti.

Odgovor:

Blok o pošiljaocu treba da sadrži:

• sertifikat javnog ključa potpisivača,
• identifikatore algoritama za kreiranje i šifrovanje potpisa poruke, i
• šifrovanog potpisa poruke.

Nije neophodno praviti više ovakvih blokova za svakog primaoca, jer se podaci u njemu ne razlikuju u zavisnosti od primaoca.

9. zadatak

Prikazano je zaglavlje jednog bloka transakcija na bitcoin blokčejnu. Ako prikazani hash odslikava zahtevanu težinu problema potvrde bloka, koliko je prosečno potrebno različitih Nonce vrednosti da bude isprobano dok se ne dobije odgovarajuća potvrda transakcije? Smatrati da je raspodela hash funkcije uniformna. Odgovor dati u obliku 2^n.

• Number Of Transactions: 1502
• Transaction Volume: 316.33241479 BTC
• Transaction Fees: 0.06640796 BTC
• Height: 685698
• Time: 2021-05-31 22:38:48
• Bits: 386752379
• Size: 896,885(bytes)
• Version: 536870916
• Nonce: 432023578
• Block Reward: 6.25 BTC
• Days Destroyed: 6,678
• Hash: 00000000000000000007ab43dfc1a8f73101f5fa2cd85dea59cdaf8f8d858351

Odgovor: 2^77

Objašnjenje: Broj 00000000000000000007ab43dfc1a8f73101f5fa2cd85dea59cdaf8f8d858351 u binarnoj reprezentaciji ima 77 nula na početku. Priznavan je takođe bio i odgovor 2⁷⁶, jer se u zadatku tražio prosečan broj različitih Nonce vrednosti. Odgovori 2¹⁹ i 2¹⁸ bili su priznavani sa polovinom bodova.

RTI

1. zadatak

Ovaj zadatak nije potpun. Ukoliko se sećate tačnih brojeva, možete ga upotpuniti.

[5 poena] Isto zadatak kao i na četvrtom izazovu, samo drugačiji potpis. (Verifikacija El Gamal potpisa)

2. zadatak

[0 poena] Predaja koda korišćenog za rešavanje prvog zadatka.

3. zadatak

[3 poena] Šta je od navedenog tačno za eXtended Merkle Signature Scheme?

1. Manji ključ od RSA
2. Veći ključ od RSA
3. Mora da pamti stanje
4. Ne mora da pamti stanje
5. Može da potpisuje više dokumenata
6. Ne može da potpisuje više dokumenata

4. zadatak

[3 poena] Isti zadatak kao i 4. zadatak iz juna 2022.

5. zadatak

Овај задатак није решен. Помозите SI Wiki тако што ћете га решити.

[5 poena] Dat je digitalni sertifikat sličan onom iz 2. zadatka iz juna 2022.. Potrebno je objasniti precizno šta se sve i na koji način treba obaviti kako bi browser mogao da verifikuje sertifikat.

6. zadatak

[4 poena] Isti zadatak kao i 6. zadatak iz avgusta 2021.

7. zadatak

[2 poena] Koji ključ povezuje vlasnika platforme i proizvođača hardvera u AMD-SEV lancu sertifikata?

1. ARK
2. ASK
3. CEK
4. OCA
5. PEK
6. PDH

8. zadatak

[3 poena] Koji od navedenih sertifikata se generišu na osnovu glavne tajne?

1. VEK
2. TIK
3. KIK
4. TEK
5. KEK

9. zadatak

[5 poena]

• Dat je deo šeme PGP protokola. Ova šema obezbeđuje autentikaciju. (Netačan odgovor donosi -1 poen, odgovor ne znam donosi 0 poena)

PGP šema uz deveti zadatak.

Neka je pošiljalac X, a primalac Y.

• Deo 1 je zapravo lozinka.
• Deo 2 je zapravo Enkriptovan(PRx).
• Deo 3 je zapravo ID(PUx).
• Deo 4 je zapravo PRx.

10. zadatak

[3 poena] Greškom došao Chacha, to je kolokvijumsko gradivo.

11. zadatak

Овај задатак није решен. Помозите SI Wiki тако што ћете га решити.

[5 poena] Precizno objasniti kako se autentikuje klijent od strane servera ako ima autentikacije kod TLS Handshake protokola.

12. zadatak

[3 poena]

1. GCM za tajnost koristi Counter.
2. GCM za autentikaciju koristi CBC.
3. Kod GCM u procesu dešifrovanja primenjuje se enkripcioni algoritam.

13. zadatak

[4 poena] Исти задатак као и 4. задатак из јуна 2022.