Jó napot! Szeretném megosztani a tapasztalataimat ezzel a témával kapcsolatban.
A RUTOKEN hardveres és szoftveres megoldások az azonosítás, az információvédelem és az elektronikus aláírás területén. Gyakorlatilag ez egy olyan USB flash meghajtó, amely tárolhatja azokat az azonosító adatokat, amelyeket a felhasználó a rendszerbe való belépéshez használ.
Ebben a példában a RUTOKEN ECP 2.0 használatát mutatjuk be.
A RUTOKEN használatához szükséges.
Windows alatt az, hogy csak az illesztőprogramot telepítjük, elegendő ahhoz, hogy az operációs rendszer észlelje a RUTOKEN-t és tudjon vele dolgozni.
A RUTOKEN-nel különböző módokon lehet interakcióba lépni. Hozzáférhetünk a szerveroldali alkalmazásból, vagy közvetlenül az ügyféloldalról is. Ebben a példában a RUTOKEN-nal való interakciót az alkalmazás ügyféloldaláról vizsgáljuk.
Az alkalmazás ügyféloldala a RUTOKEN-nel a RUTOKEN bővítményen keresztül lép kapcsolatba. Ez egy program, amelyet külön kell telepíteni minden böngészőre. Windows esetén csak le kell tölteni és telepíteni a bővítményt, .
Most már képesek vagyunk interakcióba lépni a RUTOKEN-nal az alkalmazás ügyféloldaláról.
Ebben a példában egy felhasználó azonosítási algoritmusának megvalósításának ötletét vizsgáljuk a challenge-response séma segítségével.
Az ötlet lényege a következő:
- Az ügyfél azonosítási kérelmet küld a szervernek.
- A szerver az ügyfél kérésére válaszként egy véletlenszerű karakterláncot küld.
- Az ügyfél a karakterláncot 32 véletlenszerű bittel egészíti ki.
- Az ügyfél aláírja a kapott karakterláncot a saját tanúsítványával.
- Az ügyfél a szervernek küldi el a kapott titkosított üzenetet.
- A szerver ellenőrzi az aláírást, így megszerzi az alapértelmezett, nem titkosított üzenetet.
- A szerver leválasztja az utolsó 32 bitet a kapott nem titkosított üzenetről.
- A szerver összehasonlítja a kapott eredményt azzal az üzenettel, amelyet az azonosítási kérés során küldtek.
- Ha az üzenetek megegyeznek, az azonosítás sikeresnek számít.
A fenti algoritmusban van egy olyan fogalom, mint a tanúsítvány. E példa keretein belül bizonyos kriptográfiai elméletet kell értenünk. A Habr-on található egy .
Ebben a példában aszimmetrikus titkosítási algoritmusokat fogunk használni. Az aszimmetrikus algoritmusok megvalósításához kulcspárra és tanúsítványra van szükség.
A kulcspár két részből áll: a magánkulcsból és a nyilvános kulcsból. A magánkulcs, ahogy a neve is mutatja, titkosnak kell lennie. Ezt használjuk az információk visszafejtésére. A nyilvános kulcsot bárkinek át lehet adni. Ez a kulcs az adatok titkosítására szolgál. Így bármely felhasználó titkosíthatja az adatokat a nyilvános kulcs használatával, de csak a magánkulcs birtokosa képes visszafejteni ezeket az információkat.
A tanúsítvány egy elektronikus dokumentum, amely tartalmazza a tanúsítvány birtokosának, illetve a nyilvános kulcsnak az információit. A tanúsítvánnyal a felhasználó bármilyen adatot aláírhat, és elküldheti a szerverre, amely ellenőrizheti ezt az aláírást és visszafejtheti az adatokat.
A tanúsítványos üzenet helyes aláírásához azt helyesen kell létrehozni. Ehhez a RUTOKEN-en először létrejön a kulcspár, majd a kulcspár nyilvános kulcsának a tanúsítványhoz kell kapcsolódnia. A tanúsítványnak pontosan azt a nyilvános kulcsot kell tartalmaznia, amely a RUTOKEN-en található, ez nagyon fontos. Ha csak úgy létrehozunk egy kulcspárt és tanúsítványt közvetlenül az alkalmazás kliensoldalán, akkor hogyan tudja a szerver visszafejteni ezt a titkosított üzenetet? Hiszen semmit sem tud a kulcspárról vagy a tanúsítványról.
Ha mélyebbre ásunk ebben a témában, érdekes információkat találhatunk az interneten. Léteznek bizonyos hitelesítő központok, amelyeket előre megbízunk. Ezek a hitelesítő központok tanúsítványokat adhatnak ki a felhasználóknak, amelyeket a saját szerverükön telepítenek. Ezután, amikor a kliens kapcsolatba lép ezzel a szerverrel, látja ezt a tanúsítványt, és azt is, hogy azt egy hitelesítő központ állította ki, tehát bízhat ebben a szerverben. További részletek arról, hogyan kell mindent helyesen beállítani, szintén bőségesen elérhetők az interneten. .
Ha visszatérünk a feladatunkhoz, a megoldás nyilvánvalónak tűnik. Valamilyen módon létre kell hoznunk a saját hitelesítő központunkat. De előtte tisztáznunk kell, hogy mire alapozva adhatja ki a hitelesítő központ a tanúsítványt a felhasználónak, hiszen róla semmit sem tud. (Például a neve, családi neve stb.) Van egy dolog, amit tanúsítványkérésnek hívnak. Erről a szabványról részletesebben a wikipédián lehet olvasni.
A 1.7-es verziót fogjuk használni – PKCS#10.
Leírjuk a tanúsítvány létrehozásának algoritmusát a RUTOKEN-en (forrás – ):
- A kliensen létrehozunk egy kulcspárt és elmentjük a RUTOKEN-en. (az mentés automatikusan történik)
- A kliensen létrehozunk egy tanúsítványkérést.
- A kliensről elküldjük ezt a kérelmet a szerverre.
- A tanúsítványkérés szerverre érkezésekor kiállítjuk a tanúsítványt saját hitelesítő központunkkal.
- Elküldjük ezt a tanúsítványt a kliensnek.
- A kliensen elmentjük a tanúsítványt a RUTOKEN-re.
- A tanúsítványnak kapcsolódnia kell ahhoz a kulcspárhoz, amelyet az első lépésben hoztunk létre.
Most már világos, hogyan tudja a szerver dekódolni a kliens aláírását, hiszen ő állította ki a tanúsítványt.
A következő részben részletesen megvizsgáljuk, hogyan állíthatjuk be a saját hitelesítő központunkat egy teljes értékű, nyílt forráskódú kriptográfiai könyvtár, az openSSL alapján.
Forrás: habr.com
