Az SPKM ( angolul The Simple Public-Key GSS-API Mechanism - egy egyszerű mechanizmus [1] GSS-API nyilvános kulcsú infrastruktúrán alapul ) egy olyan hálózati protokoll , amely nyilvános kulcsú infrastruktúrával rendelkezik, nem szimmetrikus kulccsal . A protokollt hitelesítésre , kulcsgenerálásra, adatintegritásra és bizalmas kezelésre használják.
1993 szeptemberében jelent meg a GSS-API [2] [3] első verziója , és ekkorra megjelenik a Kerberos V5 mechanizmus [4] is . De míg a Kerberos 5 széles körben használt, bevett protokoll lett sok rendszerben, egyes alkalmazásoknak nyilvános kulcsú infrastruktúrára kell építeniük egy GSS-API-t, nem pedig szimmetrikus kulcsú infrastruktúrára. Ennek eredményeként 1996 októberében Carlisle Adams megalkotta az SPKM protokollt (az első két változatát). Az NFSv4 2000-es létrehozásakor azonban felmerült a kölcsönös hitelesítés és a biztonságos csatorna létrehozásának problémája egy névtelen felhasználó és a szerver között, ami az SPKM-3 megjelenéséhez vezetett.
A fenti tulajdonságokból az következik, hogy az SPKM rugalmassággal és funkcionalitással rendelkezik, szükségtelen bonyolultság és megvalósítási többlet nélkül. Mivel az SPKM megfelel a GSS-API-nek, egy alkalmazás alternatív hálózati biztonsági protokollként használhatja (például Kerberos helyett) [6] .
Az Általános biztonsági szolgáltatások programozási felületének (GSS-API) leírása a szerint 2 részre osztható [2] :
Az SPKM egy példa az utóbbi dokumentumtípusra, ezért "GSS-API mechanizmusnak" nevezik. Ez a mechanizmus hitelesítést, kulcsgenerálást, adatintegritást és adatok bizalmas kezelését biztosítja az online elosztott alkalmazásokban nyilvános kulcsú infrastruktúra használatával. Az SPKM használható bármely más olyan alkalmazás helyettesítésére, amely biztonsági szolgáltatásokat használ GSS-API-hívásokon keresztül (például egy olyan alkalmazás, amely már használja a Kerberos GSS-API-t). A nyilvános kulcsú infrastruktúra használata lehetővé teszi az elektronikus aláírások használatát a szerzőség megtagadásának elkerülése érdekében az üzenetküldés során, és egyéb előnyöket is biztosít, mint például a méretezhetőséget a felhasználók nagy csoportjai számára.
Az SPKM-ben definiált tokeneket a GSS-API [2] működési paradigmájának megfelelően az alkalmazási programok általi használatra szánják . Ez a következő módon működik. A GSS-API-t általában egy hálózati protokoll (vagy egy azt használó alkalmazás) hívja meg a hitelesítési, bizalmassági és/vagy adatintegritási szolgáltatásokkal való kapcsolat biztosítása érdekében. A GSS-API hívásakor a protokoll (alkalmazás) elfogadja a GSS-API (helyi) implementációja által biztosított tokeneket (vagyis a GSS-API mechanizmust), és továbbítja a tokeneket a távoli rendszernek, a másik végén a token fogadása és további feldolgozása már a saját GSS-API mechanizmusán keresztül történik. Így maga a GSS-API nem nyújt biztonsági szolgáltatásokat, hanem interfészt biztosít az alkalmazások és a GSS-API implementációk (mechanizmusok) között. Ezek pedig GSS-API-kompatibilis felületet biztosítanak, lehetővé téve olyan alkalmazások létrehozását, amelyek különböző biztonsági mechanizmusokkal működnek; lehetővé teszi a mechanizmusok cseréjét az alkalmazások átírása nélkül.
Az SPKM különböző implementációi közötti legalább minimális kompatibilitás biztosítása érdekében az egyik integritás-algoritmust kötelezővé tették (KÖTELEZŐ), az összes többi algoritmust és példát pedig opcionálisan támogatják a különféle implementációk, egyes algoritmusok ajánlottként is meg vannak jelölve (AJÁNLOTT), ez a kompatibilitás növelése érdekében történik [6] .
Az SPKM protokoll a következő algoritmusokat használja:
Annak biztosítására szolgál, hogy az adatokat harmadik fél ne módosítsa. Az algoritmustól függően ez is biztosíthatja az üzenet szerzőségének megbízhatóságát és lehetetlenségét.
A következő algoritmusok használhatók példaként (az algoritmusazonosítók alább találhatók):
md5WithRSAEncryption OBJECT AZONOSÍTÓ ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 //kölcsönzött a PKCS#1 -ből }Ez az algoritmus kötelező (KÖTELEZŐ) az SPKM-hez. Az MD5 hash függvényen alapuló RSA elektronikus aláírás kiszámításával biztosítja az adatok integritását, hitelességét és letagadhatatlanságát . Mivel jelenleg ez az algoritmus az egyetlen szükséges integritási és hitelesítési algoritmus, az interoperabilitás érdekében azt is előírták, hogy az md5WithRSA legyen az összes kapcsolati token aláíró algoritmusa, amelyben az integritás ellenőrzése aláírással történik, és nem MAC-on alapul. Talán a jövőben lesznek más kötelező algoritmusok, és akkor ez a markerekre rótt feltétel megszűnik [6] .
DES-MAC OBJECT AZONOSÍTÓ ::= { iso(1) azonosított szervezet(3) oiw(14) secsig(3) //a MAC hosszát bitben egész számként tárolja, algoritmus(2) 10 //8 többszörösére korlátozva, 16-tól 64-ig }Ez az algoritmus AJÁNLOTT, és az integritást DES-alapú MAC használatával kényszerítik ki.
md5-DES-CBC OBJEKTUMAZONOSÍTÓ ::= { iso(1) azonosított szervezet(3) dod(6) internet(1) biztonság(5) integritás(3) md5-DES-CBC(1) }Itt az adatok integritását a DES- CBC -n alapuló titkosítás és "vegyes" MD5 hashelés biztosítja. Ez a gyakorlatban gyorsabb, mint a DES-MAC számítás, ha a bemeneti adat kicsi (néhány bájt nagyságrendű). Ne feledje, hogy gyúrás nélkül a mechanizmus integritása legfeljebb a DES erejével egyenlő egy ismert egyszerű szöveges támadásokkal szemben.
sum64-DES-CBC OBJECT AZONOSÍTÓ ::= { iso(1) azonosított szervezet(3) dod(6) internet(1) biztonság(5) integritás(3) sum64-DES-CBC(2) }Ez az algoritmus biztosítja az adatok integritását a DES CBC titkosítással. A "vegyes" adatok és az összes bemeneti adatblokk összegének összefűzése (az összeget a modulo 2 64 - 1 összeadás segítségével számítjuk ki ). Ebben az algoritmusban tehát a titkosítás szükséges feltétele az adatok integritásának biztosításának [6] .
Ezeket a szimmetrikus algoritmusokat használják a GSS-API hívások adatainak titkosításához: gss_seal() / gss_wrap() .
Példa:
DES-CBC OBJEKTUMAZONOSÍTÓ ::= { iso(1) azonosított szervezet(3) oiw(14) secsig(3) algoritmus(2) 7 }Ez az algoritmus AJÁNLOTT.
A csomópontok által a kapcsolat során használt szimmetrikus kulcs létrehozására szolgál. Továbbá ebből a kulcsból létrejönnek az integritási és bizalmassági algoritmusok alkulcsai. A kulcsgenerálás az X.509 hitelesítési csere során történik, így a kapott szimmetrikus kulcs hitelesítésre kerül.
Példák:
RSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 // a PKCS#1-ből és az RFC-1423- ból kölcsönzött }Ebben a KÖTELEZŐ algoritmusban a kapcsolati kulcsot a kezdeményező hozza létre a cél RSA nyilvános kulcsával, és elküldi neki. A célt viszont nem kell megválaszolni ahhoz, hogy a kulcs létrejöjjön.
dhKeyAgreement OBJECT AZONOSÍTÓ ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-3 (3) 1 }Ebben a példában a kulcsot mindkét csomópont generálja a Diffie-Hellman algoritmus segítségével . Így a célnak válaszolnia kell a kezdeményezőnek a kapcsolat létrehozásához (ezért ez az algoritmus nem használható egyirányú hitelesítéssel az SPKM-2-ben).
A csatlakozási kulcs K-ALG használatával generálásával a csomópontoknak alkulcsokat kell beszerezniük a titoktartási és integritási algoritmusokhoz. Ehhez egyirányú funkciókat használnak . Hagyja, hogy az elfogadott adatvédelmi algoritmusok listája sorban legyen számozva, vagyis az első algoritmushoz (az alapértelmezett algoritmushoz) a 0, a másodikhoz az 1-es szám tartozik, és így tovább. Az integritás-algoritmusok listája ugyanígy legyen számozva. Végül legyen az összekapcsoló kulcs egy tetszőleges M hosszúságú bináris karakterlánc , a korlátozások függvényében:
L ≤ M ≤ UAz összekapcsoló kulcs bithosszának nagyobbnak kell lennie az alkulcsok legnagyobb bithosszánál (C-ALG vagy I-ALG), ugyanakkor felülről a kulcslevezetési algoritmus bemeneti paraméterei határolják ( K-ALG).
Például, ha DES-t és 3-DES-t használ az adatvédelmi algoritmusokban, és DES-MAC-t az integritás-algoritmusban, az összekapcsolási kulcsnak legalább 112 bitesnek kell lennie. Az 512 bites RSA használatakor pedig a lehetséges hossz 424 bit (a legnagyobb megengedett RSAEncryption bemeneti paraméter, a PKCS#1 leírása). Másrészt a dhKeyAgreement algoritmus használatakor a csatlakozási kulcsot a Diffie-Hellman algoritmus számítja ki (kivéve a magas bájtot, amelyet biztonsági okokból eldobunk), így annak hossza 8 bittel lesz kisebb, mint a p modulus, ami megközelítőleg 1000 bit [6] .
A k-bites alkulcs megszerzésének algoritmusa a következőképpen van meghatározva:
rightmost_k_bits ( OWF (context_key || x || n || s || context_key ) ) ahol:kontextus_kulcs – csatlakozási kulcs;
x - „C” ASCII-karakter (0x43) a titoktartási algoritmus alkulcsának létrehozásakor, „I” ASCII-karakter (0x49) az integritás-algoritmus alkulcsának létrehozásakor;
n az algoritmus száma a megfelelő engedélyezett listában (ASCII karakter "0" (0x30), "1" (0x31) és így tovább);
s - a feldolgozás "szakasza" - mindig megegyezik a "0" (0x30) ASCII karakterrel, ha a "k" nem nagyobb, mint az egyirányú függvény (OWF) kimeneti mérete, ebben az esetben az egyirányú függvény újraszámítva a "szakasz" értékének növelésével (az OWF minden kimeneti értéke az előzőek végéhez fűzve), amíg "k" bit nem keletkezik;
|| - összefűzési művelet;
Az OWF a megfelelő egyirányú függvény.
Példák:
MD5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5 }Ez az algoritmus kötelező (KÖTELEZŐ).
SHA OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 18 }A meglévő hash függvények nem egyeznek meg az egyirányú függvények összes tulajdonságával. Ezért a kapcsolatlétesítési folyamat során alkulcs-levezetési algoritmus egyeztetést alkalmaznak, amely lehetővé teszi a jövőbeni egyirányú funkciójavítások egyeztetését a régebbi verziókkal.
Az SPKM-ben történő kapcsolat létrehozása során a kezdeményező számos lehetséges adattitkossági és integritási algoritmust javasol (beleértve az elektronikus aláírási algoritmusokat is). A vevő kiválasztja, hogy a létrehozott kapcsolat mely algoritmusait használja, és visszaküldi a támogatott algoritmusok javított listáját. A létrehozott kapcsolaton keresztül továbbított minden üzenet bármilyen titkossági és integritási algoritmust használhat, a lista elsőként felsorolt algoritmusai az alapértelmezettek. Az adott kapcsolatra alkalmazott titkossági és integritási algoritmusok meghatározzák a védelmi minőségi paraméter ( Quality Of Protection) értékeit, amelyeket a gss_getMIC ( ) és gss_wrap ( ) függvények használnak , amelyek kiszámítják a kriptográfiai üzenet integritási kódjait és csatolják azt az üzenet. Ha nem várható válasz a vevőtől (egyirányú hitelesítés az SPKM-2-ben), akkor a forrás által kínált algoritmusok kerülnek felhasználásra az üzenetátviteli folyamatban. Ha a vevő nem támogatja az alkalmazott algoritmusokat, akkor kapcsolatlezáró tokent (delete tokent) küld a forrásnak, és a kapcsolat megszakad.
Ezenkívül az első kapcsolatlétesítési jogkivonatban az origó számos lehetséges kulcsgeneráló algoritmust (K_ALG) javasol a lista első algoritmusának megfelelő kulccsal (vagy a kulcs felével) együtt. Ha ez az algoritmus nem elfogadható, akkor a vevőnek ki kell választania egyet a listából a többi közül, és el kell küldenie a választását a kiválasztott algoritmusnak megfelelő kulccsal (fele) együtt. Ha a vevőnek küldött lista nem tartalmaz általa támogatott algoritmust, akkor szétkapcsoló jelzőt küld a forrásnak. Ha szükséges (ha a vevő kétirányú kulcsgenerálási algoritmust választ, mint a Diffie-Hellman algoritmus esetében), a forrás visszaküldi a kulcs felét a vevőnek. Végül az első kapcsolatlétesítési jogkivonatban a forrás számos engedélyezett alkulcs-generálási algoritmust kínál, de ha egyirányú hitelesítést használunk, akkor csak egy algoritmust kínál fel. A vevő által választott (az egyetlen) algoritmus lesz az alkulcs megszerzésének algoritmusa a létrehozott kapcsolatban [6] .
Az SPKM-ben használt tokenek működésének megértéséhez nézzünk meg egy példát egy véletlen számokon alapuló kapcsolat létrehozására. Nem térünk ki az összes elérhető tokenre és funkcióra, a teljes lista megismeréséhez, leírásuk és megvalósításuk megtekintéséhez jobb, ha az RFC 2025 -re hivatkozunk .
A bemutatott diagramon a kapcsolat kezdeményezője meghívja a gss_init_sec_context() függvényt , amely egy SPKM_REQ tokent ad vissza , amelyet azután elküld a vevőnek a használt hálózati protokoll segítségével. A vevő, miután megkapta ezt a tokent, átadja a gss_accept_sec_context() -nek , amely eredményként az SPKM_REP_TI -t adja vissza . A vevője visszaküldi a kezdeményezőnek. Ez viszont ezt a jelölőt használja bemeneti paraméterként a gss_init_sec_context() második hívása során . Ha a kezdeményező egyirányú hitelesítést használt, akkor a kapcsolat létrehozása itt ér véget. Ellenkező esetben (például ha kezdetben kölcsönös hitelesítés szükséges) a gss_init_sec_context() az SPKM_REP_IT értéket adja vissza , amelyet elküld a fogadónak. Ezt a tokent használja a gss_accept_sec_context() második hívása során, és ezzel befejezi a kapcsolat beállítását. Ezt követően a felek SPKM_MIC és SPKM_WRAP tokeneket cserélhetnek mindaddig, amíg az egyik fél elküldi az SPKM_DEL-t a kapcsolat megszakítására [5] .
Az SPKM_REQ marker egyéb adatmezők mellett a következő elemeket tartalmazza:
Ezen adatok sértetlensége védett, és a csatlakozást kezdeményező elektronikus aláírásával is aláírja. Ha névtelen szeretne maradni, ebben az esetben az integritást MAC védi. Opcionálisan a digitális tanúsítványokkal kapcsolatos információk küldhetők el ebben a tokenben .
Az SPKM_REP_TI marker a következőket tartalmazza:
Ezen adatok sértetlensége védve van, és a címzett elektronikus aláírásával is aláírják. Ne feledje, hogy a kezdeményezőnek a fogadó által aláírt véletlenszáma garantálja, hogy a vevő „él” és megbízható. A digitális tanúsítványokkal kapcsolatos információk ebben a tokenben küldhetők el, ha a kezdeményező kéri az SPKM_REQ -ban .
Ha a kölcsönös hitelesítés van kiválasztva, akkor az SPKM_REP_IT token kerül felhasználásra , amely a következő mezőket tartalmazza:
Ezen adatok sértetlensége védve van, és a kezdeményező elektronikus aláírásával is aláírják. Vegye figyelembe, hogy a kezdeményező által aláírt címzett véletlenszerű száma garantálja számára, hogy a kezdeményező „él” és megbízható.
A véletlenszámú kapcsolat létrehozása után mindkét fél hitelesítésre kerül (megbízható időbélyegek használata nélkül), a kapcsolati kulcs biztonságosan létrejött, a két algoritmuskészlet (bizalmasság és integritás) megegyezik a kapcsolat során történő használatáról. MIC és WRAP műveletek . Mindegyik SPKM_MIC , SPKM_WRAP és SPKM_DEL marker kifejezetten megadhatja a megfelelő algoritmust az egyeztetett listából, amelyet a jelölőhöz társított adatokhoz használ, vagy használhatja az "alapértelmezett" algoritmusokat (azaz az egyes listák első algoritmusait).
SPKM_MIC – aláírásra és adatintegritás ellenőrzésére szolgál (gss_sign() / gss_getMIC())
SPKM_WRAP – titkosításra (dekódolás) és adatvédelemre szolgál (gss_seal() / gss_wrap())
SPKM_DEL – a kapcsolat megszakítása (gss_delete_sec_context()).
Ezért a markerek a következő információkat tartalmazzák:
Ez a token formátum nagyobb rugalmasságot biztosít az alkalmazások hívásakor a védelem minőségének (QOP) kiválasztásához, amely megfelel a védett adatoknak a létrehozott kapcsolaton belül [5] .
Az SPKM-nek eredetileg két változatát írták le: az SPKM-1-et és az SPKM-2-t, a fő különbség az, hogy az SPKM-2 megbízható időbélyegeket igényel a kapcsolat létrehozása során történő újrafelderítéshez, míg az SPKM-1 nem. Ez nagyobb rugalmasságot biztosít az alkalmazások számára, mivel nem mindig lehetséges megbízható időbélyegeket használni a rendszerben. Amikor 2000-ben létrehozták az NFSv4 protokollt, felmerült az igény egy olyan mechanizmusra, amely biztonságos csatorna létrehozását biztosítja kölcsönös hitelesítéssel, ahol:
Így jelent meg az SPKM-3, amely a LIPKEY kiegészítő segítségével a hálózati fájlrendszerek működésének alapja [8] [9] . Mindenekelőtt a hitelesítési eljárás egyszerűsítése érdekében hozták létre. Tekintsük ezt a mechanizmust részletesebben.
Ügyfél:
Így biztonságos kapcsolat jön létre a kliens és a szerver között, ahogy itt is látható, a Diffie-Hellman algoritmus használatos. A kliens megadhatja bejelentkezési nevét és jelszavát a hitelesítéshez (illetve a tanúsítványokhoz), azonban erre nincs szükség, vagyis a kliens névtelen maradhat.
Amint látható, a használt hitelesítési mechanizmus hasonló a TLS-hez, de az egyszerűség és a kényelem mellett a fő hátrányt is örökölte – egy ember a közepén támadás lehetőségét [10] .
A GSS-API ( általános biztonsági szolgáltatás - alkalmazásprogramozási felület - általános biztonsági szolgáltatás - alkalmazásprogramozási felület ) lehetővé teszi az alkalmazás számára, hogy hitelesítsen egy másik alkalmazásnak megfelelő felhasználót, hogy jogokat biztosítson neki, és minden egyes üzenethez bizalmassági és adatintegritási biztonsági szolgáltatásokat alkalmazzon.
A GSS-API használatának 4 lépése van:
| Hitelesítési és kulcscsere protokollok | |
|---|---|
| Szimmetrikus algoritmusokkal | |
| Szimmetrikus és aszimmetrikus algoritmusokkal | |
| Az interneten használt protokollok és szolgáltatások | |