SSL és TLS
Az SSL (Secure Sockets Layer) és TLS (Transport Layer Security) titkosítási protokollok a modern hálózatok alappillérei. Minden bizonnyal, aki élete során találkozott már az internet bármiféle megjelenésével, az ezeket a protokollokat használta is közvetett módon, legegyszerűbb formájában egy HTTPS protokollon elérhető weboldal meglátogatásával. Az SSL a TLS protokoll elődje, aminek az első 2.0 verziója 1995-ben került publikálásra. Jelenleg a legfrissebb változat a TLS 1.3 ami 2018 márciusában jelent meg.
Ezeknek a protokolloknak a célja, hogy az elküldött adatcsomagok idegenek által ne legyen olvasható, ne legyen módosítható és ne legyen átirányítható. Ezeket a feltételeket két módszer segítségével biztosítják: titkosításra kerül az adatcsomagok tartalma, illetve digitális aláírással látják el a kommunikáló felek a küldött csomagokat. Ezek megvalósítására a kommunikáló felek tanúsítványokat, nyilvános kulcsokat és privát kulcsokat használnak.
Tanúsítványok, a bizalmi lánc
A magas fokú biztonság megtartásának érdekében felhasználónév és jelszó párosok helyett tanúsítvány alapú hitelesítéssel működik a legtöbb ilyen titkosítás. Az alábbi módon néz ki egy tanúsítványokból felépülő bizalmi lánc.
1. ábra – „Chain of trust”, minden tanúsítványt a felsőbb réteg tanúsítványa hitelesít
A legfelső rétegben minden esetben egy gyökértanúsítvány (root CA) szerepel, ami önmagát hitelesíti. Ez az a tanúsítvány, amit egy szolgáltató abból a célból bocsát ki, hogy az alárendelt tanúsítványai, ami később például generálásra kerül rá hivatkozva érvényesek legyenek. Amennyiben egy tanúsítvány nem képes a felsőbb réteg által azonosítani magát úgy nem lesz használható, és nem hozható létre vele titkosított kapcsolat.
Amennyiben egy eszköz rendelkezik megbízható tanúsítványokkal a következő lépés, hogy ennek az eszköznek a tanúsítványát más eszközök is elismerjék. Ez általánosan úgy kerül megoldásra, hogy az eszközt kibocsátó tanúsítványt a másik fél biztonságosnak tekinti, ezáltal a belőle származtatott tanúsítványnak is biztonságosnak kell lennie.
Mi történik a háttérben?
Tételezzük fel, hogy egy kliens és egy szerver eszköz egymással titkosított kapcsolatot szeretne létesíteni. Az alábbi ábra mutatja be ennek a kézfogásos módszernek a folyamatát.
2. ábra – PKI (Public Key Infrastructure) alapú kézfogásos hitelesítés
A kliens először felveszi a kapcsolatot a szerverrel, ami ennek hatására elküldi számára a saját publikus kulcsát. A kliens erre reagálva visszaküldi a szerver számára a saját tanúsítványát, és emellett elküldi még a saját publikus kulcsát, amit a szerver kulcsával titkosított. Jelzi a szerver felé, hogy titkosítsák a kapcsolatot, ebbe ő beleegyezik és megkezdődik a titkosított kommunikáció.
A hitelesítés megtörténése után minden adatcsomag küldéskor a feladó nyilvános kulcsával titkosításra kerül, és a fogadó fél privát kulcsával pedig feloldásra. A kapcsolat biztonságát az adja, hogy a privát kulccsal ideális esetben csak a fogadó fél rendelkezik, ezért csak ő képes dekódolni a kapott üzeneteket.
3. ábra – A kriptográfiai példákban gyakran a két kommunikáló fél Alice és Bob
A legmegbízhatóbb tanúsítvány az, amit saját magunk állítunk ki
Ezeket a tanúsítványokat mi magunk is elkészíthetjük akár konzol alkalmazás segítségével (openssl, easy-rsa, …), vagy akár grafikus felülettel rendelkező alkalmazások segítségével (XCA, KeyStore Explorer, …).
Ebben a példában az XCA nevű szoftver segítségével készítünk tanúsítványokat, méghozzá két WAGO PLC (192.168.1.97 és 192.168.1.98) közötti szerver-kliens OpenVPN kommunikációhoz.
Mindenekelőtt létre kell hozni egy jelszóval védett adatbázist egy biztonságos, lehetőleg offline számítógépen (ismét a biztonság fokozása érdekében). Ez az adatbázis fogja tartalmazni a létrehozott tanúsítványokat és kulcsokat, amik bármikor exportálhatók.
4. ábra – Üres tanúsítvány adatbázis
Szükség van egy megbízható főtanúsítványra, amit jelen esetben mi magunk állítunk elő.
5. ábra – Self signed CA létrehozása, a „[default] CA” sablon jó kiindulási alap
A tárgy fülön meg kell adni a tanúsítvány fejlécében szereplő adatokat. Lényegében a legtöbb adat arra vonatkozik, hogy ki bocsátotta ki az adott tanúsítványt. Az adatok kitöltése után egy új privát kulcs generálása is szükséges. Minden tanúsítványnak erősen javasolt új kulcsot generálni.
6. ábra – Kitöltött tárgy lap
Minden tanúsítványnak van lejárati dátuma az esetleges kiszivárgások elleni védelem érdekében. Ezt a következő oldalon lehet beállítani.
7. ábra – A CA tanúsítványok lejárati dátuma több év
Ha minden rendben ment, akkor már létre is hoztuk az első saját magunk által hitelesített CA tanúsítványunkat. A későbbiekben ezzel fogjuk hitelesíteni a szerver és a kliensek számára létrehozott tanúsítványokat.
8. ábra – Sikeres CA létrehozás
A folyamatot a további tanúsítványok generálásához meg kell ismételni kisebb változtatásokkal.
9. ábra – Szerver tanúsítvány, amit a létrehozott CA ír alá
Fontos különbség, hogy milyen érték szerepel szerver és kliens tanúsítványok esetén a „commonName” mezőben. Ennek a mezőnek az értéke határozza meg azt, hogy a hálózaton ki használhatja a tanúsítványt, és ezáltal az értéke is megegyezik az eszköz saját hálózati azonosítójával. Ez lehet az eszköz hoszt neve is, de a mi esetünkben bőven elegendő a PLC- k statikus IP címét megadni.
10. ábra – A szerver tanúsítvány adatai
A következő ami még számunkra fontos, a szerver tanúsítvány lejárati dátuma. A CA tanúsítvány ugyan akár tíz évig is érvényes marad, az eszközökre vonatkozó egyedi tanúsítványokat érdemes ennél kisebb időre állítani, például csak egy évre.
11. ábra – A szerver tanúsítványa hamarabb elévül mint a CA
Végül az adatbázis az alábbi módon kell, hogy kinézzen:
12. ábra – Hiteles CA, ami aláír egy szerver és egy kliens tanúsítványt
A tanúsítványokat és a kulcsokat is ki kell exportálni, hogy különálló formátumban is elérhetőek legyenek. A CA tanúsítvány kulcsát nem szabad exportálni! Ennek a kulcsnak soha nem szabad kikerülnie a kezünk közül, hiszen ennek a kizárólagos birtoklása adja a rendszerünk biztonsági hátterét.
Az exportált fájlok formátumát a feldolgozó szoftverek határozzák meg. WAGO PLC esetén bőven elégséges hagyományos PEM formátumban (.crt vagy .pem) való exportálás. Célszerű a kulcsok kiterjesztését .key-re módosítani a későbbi könnyebb eligazodás érdekében.
Ezek mellett szükséges a szerver számára egy úgynevezett Diffie-Hellman kulcsot is biztosítani, ami szintén a titkosított kapcsolat kiépítéséhez szükséges.
13. ábra – A példa során 2048 bites DH kulcsot generáltunk
Mindezek után az exportálások, DH kulcs generálás és átnevezések után az alábbi módon kellene kinéznie a tanúsítvány gyűjteményünknek:
14. ábra – A titkosításhoz szükséges fájlok
Összegzés
A kibertámadások megszaporodásával minden lehetőséget érdemes megvizsgálni, ami adataink biztonságát szolgálja. A lehető legjobb eredmény eléréséhez mindenképp olyan technológiákat és szolgáltatásokat válasszunk, amik modern kihívásokkal szemben is magabiztosan helytállnak. A legnagyobb védelmet mindig is a tájékozottság fogja adni.