Kriptográfiai algoritmusok csoportosítása

1. Elvégzett művelet szerint
   • Keverő titkosítók: a titkosított szöveg a nyílt szöveg betűinek permutációja
     • Rail Fence Cipher
   • Helyettesítő titkosítók: a nyílt szöveg betűit egyessével vagy blokkokban a titkosított szöveg betűivel helyettesítjük.
     • Caesar kódolás

       

     • Egyszerű, egyábécés helyettesítés
     • Többábécés helyettesítés (betűnként más-más abc). Vigenére-titkosító
     • Enigma
   • Produkciós titkosítók: keverés és helyettesítés egymás utáni alkalmazásai. A keverés és a helyettesítés könnyen felfejthető akár például statisztikai alapon, kombinálva őket nehezebb lesz. A 20. század második felétől, a számítógépek egyre hangsúlyosabb megjelenésével terjedtek el. Jól ismert példák: DES, AES, Blowfish. Manapság a DES nem biztonságos, használata nem javasolt, helyette az AES javasolt. Amikor titkosított kapcsolatot használunk jó eséllyel az AES valamelyik verziója működik a titkosítási lánc egy pontján.
2. Kulcs szerint:
   • Szimmetrikus titkosítók: az összes klasszikus titkosító ilyen. Ugyanazzal a kulccsal lehet betitkosítani, amivel kititkosítani is. A fogadó és a feladó is birtokában van ennek a kulcsnak. Ha a kulcs kiszivárog, akkor a titkosságnak is vége. Modern példák: DES, AES. A fent említett nem modern titkosítók is ide sorolhatók, pl. Enigma, Caesar kódoló stb.

     

   • Aszimmetrikus titkosítók (nyilvános kulcsú titkosítók): minden résztvevő rendelkezik egy publikus - privát kulcspárral. A privát kulcsra vigyázni kell, hogy ne szivárogjon ki. A publikus kulcs meg van osztva a kommunikáció másik felével. A kulcsok matematikailag összefüggnek, de a privát kulcs nem található ki a publikusból. Amit az egyik kulccsal betitkosítunk azt csak a másikkal tudjuk kititkosítani. Az aszimmetrikus kulcsú rejtjelezés lényege, hogy a titkos kommunikáció megvalósításához nincsen szükség egy közös titkos kulcs előzetes megbeszélésére a küldő és a vevő között. Elég az üzenetet a vevő publikus kulcsával bekódolni, azt kititkosítani csak a vevő privát kulcsával lehet majd. Ahhoz, hogy ez jól működjön a feladónak meg kell győződnie róla, hogy megfelelő publikus kulccsal titkosítja be az üzenetet, nem egy rosszindualtú harmadik fél kulcsával. Egy, az aszimmetrikus titkosítók működését szemléltető oldal: link.

     

     Ismert algoritmusok ilyen aszimmetrikus titkosító rendszerekre: RSA, Diffie-Hellmann kulcscserélő protokoll és az egyre elterjedtebbé váló ECC (Elliptic Curve Cryptography) algoritmus. Mivel az aszimmetrikus titkosítás költségesebb, a legtöbbször csak annyira van használva, hogy a felek biztonságosan megegyezzenek egy szimmetrikus kulcsban, ami a session végén törölve lesz. A szerver publikus kulcsa van arra használva, hogy be legyen titkosítva ez a szimmetrikus kulcs. Az SSL, illetve az őt követő, biztonságosabb TLS algoritmus ilyen módon működik. Ezek a protokollok (most már inkább a TLS) vannak használva HTTPS használatakor is.

     

     RSA algoritmus

     Weboldal mely az RSA kulcsok előállításának menetét szemlélteti. Itt is le van vezetve az RSA algoritmus részletesen: Egy hátrány, hogy ha az üzenet túl rövid (rövidebb, mint a kulcs), akkor önmagában nem szabad RSA-val kódolni, mert brute force módon feltörhető.

TLS 1.2, 1.3

Bevezeti és preferálja a Diffie-Hellman alapú kulcscserét. Itt a szerver privát kulcsának már nincs akkora szerepe, kiszivárgása esetén nem fejthető vissza egy korábban rögzített üzenetsor. Jelenleg a szerver megszemélyesítésére lehet inkább felhasználni a kiszivárgott privát kulcsot.

1. Nyilvánosan megosztott elemek: p - nagy prímszám, g - generátor
2. Alice titkos kulcsa: a. Nem osztja meg
3. Bob titkos kulcsa: b. Nem osztja meg
4. Alice kiszámol egy értéket, amit viszont megoszt Bob-al: A = g^a mod p
5. Bob kiszámol egy értéket, amit viszont megoszt Alice-al: B = g^b mod p
6. A hálózaton a két titkos érték a és b nem halad át.
7. Alice és Bob kiszámolják a közös kulcsot
• Bob számolása
• shared = A^b mod p -> shared = (g^a mod p)^b mod p -> g^(ab) mod p
• Alice számolása
• shared = B^a mod p -> shared = (g^b mod p)^a mod p -> g^(ab) mod p

A TLS 1.3 teljesen eltávolította az RSA kulcscserét! A kezdeti handshake egyszerűsödött és gyorsabbá vált és nagyobb részt titkosítva zajlik.

ECC (Elliptic Curve Cryptography)

Az ECC egy modern aszimmetrikus titkosítási módszer, amely elliptikus görbéket használ a titkosításra és digitális aláírásokra. Az elliptikus görbe egyenlete:

y^2 = x^3 + ax + b

Az ECC előnyei az RSA-val szemben:

• Rövidebb kulcsméretek ? Kisebb számítási igény
• Gyorsabb műveletek ? Mobil és IoT eszközök számára ideális
• Kevesebb memória és sávszélesség szükséges

Alkalmazásai:

• TLS/SSL (pl. HTTPS biztonságos kapcsolatok)
• Digitális aláírások (pl. ECDSA)
• Bitcoin és más kriptovaluták
• End-to-end titkosítás (pl. Signal, WhatsApp)
• Kis teljesítményű eszközök (pl. IoT, okoskártyák)

ECC kulcsméret	RSA ekvivalens
160 bit	1024 bit
224 bit	2048 bit
256 bit	3072 bit
384 bit	7680 bit
521 bit	15360 bit

Ezek a rövidítések vajon mit jelentenek? Ha linuxra telepítettetek olyan commercial programokat, mint pl. Spotify valószínűleg találkoztatok már ezzel a két összezavaróan hasonló rövidítéssel.

A PGP a Pretty Good Privacy rövidítése. Ez kezdetben csak egy program volt, ami titkosításra és hitelesítésre volt használható. Titkosításhoz aszimmetrikus titkosítást használ, például az RSA algoritmust vagy a Diffie-Hellman algoritmust. Ebből nőtte ki magát az openPGP szabvány (RFC4880), amit más titkosítást végző programok is implementálhatnak. Ilyen például a GPG alias GnuPG/GNU Privacy Guard. Ez ingyenes és nyílt forráskódú, szemben a PGP programmal.

Kriptográfiai hash

Determinisztikus módszer, mellyel tetszőleges méretű adatot fix méretű bit sztringgé alakítunk. Egy jó hash algoritmus tulajdonságai:

• Könnyen/gyorsan számítható
• Nehéz találni két olyan inputot, amiből ugyanazt a hash értéket képezi
• Az input 1 bit-nyi módosítása is már jelentősen megváltoztatja az outputot (lavina hatás)
• Nehéz inputot találni egy adott hash-hez

Ezen tulajdonságok miatt egyirányú módszereknek tekintjük őket. Ám mivel determinisztikus algoritmusok, gyengébb hash-ek esetén brute force módszerrel végig lehet próbálgatni milyen input eredményezhetett egy adott outputot. Néhány algoritmus:

• MD5: gyenge (128 bites). Gyorsan számítható és memória hatékony is, így kiválóan alkalmas brute force támadásokra.
• SHA-1: (160 bites) 2017 óta ez is gyengének tekinthető. A SHAttered támadás bizonyította először a szándékos ütküzés lehetőségét. Ez még nem a brute - force támadás receptje, de azóta már nem csak speciális inputokra működik az ütközéses támadás.
• SHA-2: NSA által tervezett hash család (224, 256, 384 és 512 bites algoritmusok). Biztonságos.
• SHA-3: szintén biztonságos használni.

Felhasználás:

• Jelszó tárolás adatbázisban (semmiképp ne plain text-ként)
• Adat integritás ellenőrzése (nem módosította-e valaki illetéktelen az adatot)

MAC (Message Authentication Code)

Kriptográfiai funkciója az integritás és a hitelesség biztosítása. A MAC érték számításakor egy titkos kulcs lesz az adathoz téve, melyet csak a feladó és a fogadó ismernek (szimmetrikus kulcs). A kulcs biztosítja, hogy megfelelő forrásból jött az adat (hitelesség). Egyik típusa a HMAC, vagyis Hash based MAC (a MAC értéket kriptográfiai hash függvénnyel számolják)

Hol találkozunk MAC kóddal a gyakorlatban?

Ez a (szimmetrikus) JWT (JSON Web Token) alapötlete.

1. A szerver összerak egy header-t és egy JSON-t (payload):
   { "userId": 1234, "role": "student", "expires": 1710000000 }
2. A szerver generál ebből tokent, amit ezután oda-vissza küldenek egymásnak a klienssel.
   token = base64(header) + "." + base64(payload) + "." + HMAC(secret, header, payload)
3. A trükk: ha a kliens belemódosít a payloadba (pl promótálja a role-t adminná), akkor a HMAC érték is változik és érvénytelen lesz a token, amit a szervernek küld.

A szerver elküld egy payloadot a kliensnek, és a HMAC biztosítja, hogy a kliens ne tudja módosítani a benne lévő adatokat. Példa python kód

Digitális aláírás

Biztosítja az integritást, hitelességet és a letagadhatatlanságot is! Az üzenetből hash képződik, amit az üzenet feladója betitkosít a privát kulcsával. Ez az aláírás, ami el lesz küldve az üzenettel. Ezt utána csak a feladó publikus kulcsával lehet kititkosítani, amit bárki ismerhet. A privát kulcs viszont csak a feladó birtokában lehet, így senki másra nem kenheti rá a tranzakciót (a MAC a szimmetrikus kulcs miatt nem biztosítja ugyanezt).

Tanúsítványok

A tanúsítvány (certificate) egy olyan digitális dokumentum, amely igazolja, hogy egy adott személy (cég) a tulajdonosa egy publikus kulcsnak. Ezt ellenőrizheti a kliens (böngésző), amikor a TLS handshake elején elküldi a szerver a tanúsítványát. De hogy dönti el a kliens, hogy megbízhat egy tanúsítványban? Privát - publikus kulcspárt és abból tanúsítványt bárki készíthet. Itt jönnek a képbe a tanúsítvány hitelesítő hatóságok, a Certificate Authority-k (CA). Az ábra szemlélteti a működésüket.

Az igénylők elküldik a CA-nak a személyi adataikat és a publikus kulcsukat, majd a hatóság ellenőrzi a személyazonosságukat (2.) és kiállítja a publikus kulcsukat tartalmazó tanúsítványt (3.). A tanúsítvány tartalmazza a CA digitális aláírását. A kliensek tartalmaznak egy listát a megbízható CA-król. Ha egy tanúsítványt ilyen CA írt alá, akkor a böngésző megbízik benne. Jellemzően a tanúsítványok láncot alkotnak, melyek egymást hitelesítik.

• Valósítsunk meg szimmetrikus titkosítást OpenSSL-el!
  • openssl enc -nosalt -aes-256-cbc -pbkdf2 -k hello-aes -P -> AES szimmetrikus kulcs előállítása sózás nélkül. Kapcsolókról több: man openssl enc
  • openssl enc -nosalt -aes-256-cbc -in message.txt -out message.txt.enc -base64 -K [key] -iv [iv]
  • openssl enc -nosalt -aes-256-cbc -d -in message.txt.enc -base64 -K [key] -iv [iv]
• Generáltassunk OpenSSL-el egy publikus-privát kulcspárt! Adjuk ezt oda ncat-nek a titkosított kommunikációhoz!
  • openssl genrsa -out private.pem 2048 -> lesz egy privát kulcsunk
  • openssl rsa -in private.pem -outform PEM -pubout -out public.pem -> amiből kiszedjük a publikus kulcsot
  • openssl req -key private.pem -new -out cert_request.csr -> tanúsítvány kérelem készítése a privát kulcs alapján
  • openssl req -text -noout -verify -in cert_request.csr -> tényleg a publikus kulcs van benne
  • openssl x509 -signkey private.pem -in cert_request.csr -req -days 365 -out first_cert.crt -> self signed tanúsítvány létrehozása. Ez az a lépés, amit valójában a CA végezne el a saját privát kulcsával.
  • openssl x509 -text -noout -in first_cert.crt -> tanúsítvány tartalmának megtekintése
  • ncat -l --ssl-cert first_cert.crt --ssl-key private.pem localhost 5000 -> felhasználás ncat szerverhez
• Aszimmetrikus (ki)titkosítás elvégzése OpenSSL-el.
  • Titkosítás. Az üzenet címzettje Bob, ezért az ő publikus kulcsával titkosítunk. openssl rsautl -encrypt -inkey bob_public.pem -pubin -in top_secret.txt -out top_secret.enc
  • Kititkosítás. Bob kibontja a titkos üzenetet a privát kulcsa segítségével. openssl rsautl -decrypt -inkey bob_private.pem -in top_secret.enc > top_secret.txt
• Nézzük meg a böngésző segítségével a coospace tanúsítványát! Melyik hitelesítő hatóság írta alá?
• Próbáljuk ki a md5sum, sha*sum tool-okat! Keressünk online decrypter toolokat.

Többféle program és weboldal is létezik, ami megspórolja nekünk ezeket az OpenSSL parancsokat.

• Online lehetőség
  • Sokfélre célra generálthatunk tanusítványt: CA gyökér tanusítványt, aláíró tanusítványt kis készíthetünk
  • Legalul befigyel a fizetős opció, ha megbízható aláírást akarunk a tanusítványnak
• Egyszerű, könnyen installálható kulcsgeneráló a KeyStore Explorer
• Egy remek password és key manager a seahorse
  • Installáljuk fel ParrotOS-re:sudo apt install seahorse
  • Készítsünk magunknak új PGP kulcsot!
  • Írjunk alá digitálisan egy libre office dokumentumot! Leírás róla

Egyszerűbb támadási módok

Olyan módszerek, amelyek nem egy hiba/sérülékenység kihasználásán alapulnak.

• Brute force/teljes kipróbálás: összes lehetséges kulcs kipróbálása. A kulcs hosszával exponenciálisan nő a kitalálási idő.

  

• Dictionary attack, szótár alapú támadás: a lehetséges kulcsok össze vannak gyűjtve egy szótárban (Pl. potenciális jelszavak a gyakori lehetőségekkel) Nincs a teljes kulcstér lefedve, így gyorsabb, de nem biztos, hogy eredményes.
• Hibrid módszerek: egy lehetséges jelszó végigpróbálgatása számokkal, egyéb karakterekkel stb.
• Szivárványtábla alapú módszerek: A szivárványtáblák jelszavakat és a hozzájuk tartozó hash értékeket tartalmazzák. Egy jó szivárványtábla sokat ér, mivel költséges őket generálni. Online hash képző oldalak is felhasználhatják az inputjainkat szivárvány táblához. Az adatbázisokban azért jó salt-al együtt letárolni a jelszavakat, hogy ha valaki ugyanazt a jelszót is használja több fiókhoz, a salt-olt hash érték más les és nem működnek az ilyen előre kiszámolt táblák.

  Ha nincs só a tároláskor a támadó egyszer kiszámolja a gyakori jelszavakra a hash-eket és egy adatbázis megszerzése után fel tudja használni ezt a táblát a jelszavak kitalálásához (gyakorlatilag költségmentes a generálás után)

  • SHA256("password") -> 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
  • Ha nincs só minden adatbázisban ugyanezek a hash-érték szerepel!!!
  Ha van random só minden user-hez...
  • SHA256("password" + "A1B2") -> 80b94e18f0aedb468c4acde99320fc74b7826de571baf70ff4e44c3b1d87c4f3
  • SHA256("password" + "XYZ2") -> 125d3276e8eeb7ef6671d42c6423a13350f4a1a6fdc48138f3403ee30175c9b5
  • Az előre számolt tábla használhatatlan! Ha ugyanazt a je4lszót használja két user akkor se lesz azonos a hash

John the Ripper

A John the Ripper az egyik legjobb, leggyorsabb jelszó feltörő alkalmazás, ráadásul nyílt forráskódú! Több száz hash algoritmust és titkosítót támogat. Mi szükségünk van egy ilyen programra a kártékony felhasználáson kívül? Tudjuk vele detektálni egy rendszer gyenge jelszavait.

Próbáljunk ki egy egyszerű John alkalmazást. Szerezzük meg egy jelszóval védett zip jelszavát. Ehhez két parancsra van szükség:

• zip2john titkos.zip > zip.hashes -> kinyerjük a jelszó hash-ét a zip-ből
• john --wordlist=/usr/share/wordlists/metasploit/unix_passwords.txt zip.hashes -> megtaláljuk a hash-hez tartozó jelszót egy jelszógyűjtemény segítségével. A John minden jelszót elhashel és összeveti őket. Időigényes lehet.
• Ha nem találja bekapcsolhatjuk, hogy szabályok alapján mutálja a jelszavakat: --rules
• Ha nem találja meg a john próbáljunk ki másik szólistát! Tipp: rockyou.txt
• john --show zip.hashes

Obfuszkálás

Forráskód olvashatatlanná/nehezen olvashatóvá tétele az eredeti funkció megtartása mellett. A cél:

• a forráskód visszafejtésének, ellopásának nehezítése
• értékes algoritmusok védelme
• kártékony kódrész elrejtése
• Másolásvédelmi funkciója is lehet: minden vevő másképp obfuszkált kódot kap. Ki kezdte el a másolást?

Különböző szintjei lehetnek. A legalapvetőbb obfuszkálás csak lecseréli a változóneveket, de létezik ennél komolyabb, pl. control flow obfuszkálás, ami a kód működését próbálja elrejteni. Egy utasítás helyettesítése többel, elérhetetlen kód beszúrása stb.

Szteganográfia

Az üzenetet azáltal "titkosítjuk", hogy megpróbáljuk eltitkolni/elrejteni a létezését. Kriptográfia esetén az üzenet meglétét nem titkoljuk. Szteganográfia pl. egy üzenet elrejtése egy képben. Ókori görög példa: leborotválták a rabszolga haját, rátetoválták az üzenetet, majd megvárták, amíg visszanő és elküldték a címzetthez.

Napjainkban ez azt jelenti, hogy digitáis üzeneteket rejtünk el digitális tartalmakban. Ez lehet a már említett képben való elrejtés, de más módok is elképzelhetőek:

• vesszők rendhagyó elhelyezése szövegben
• szöveg sorainak első betűivel kódolt üzenet
• sorvégi szóközökkel, tabulátorokkal való elrejetés (SNOW)

Ingyenesen elérhető a Steghide nevű program. Telepíthetjük a Kali-nkra, ha az alábbi csomagokat a /var/cache/apt/archives mappába másoljuk. Ha működik az apt install steghide parancs, akkor nem szükséges letölteni sem. Próbáljuk is ki!

• steghide embed -ef message.txt -cf catto.jpg -sf result.jpg
• steghide extract -sf result.jpg -xf message_extracted.txt

Nem szigorúan vett szteganográfia, de a polgármester választási időszakban a fideszes jelölt oldalán "elrejtett" üzenetre is érdemes visszaemlékeznünk.