SPKM ( anglicky The Simple Public-Key GSS-API Mechanism - jednoduchý mechanismus [1] GSS-API založený na infrastruktuře veřejného klíče ) je síťový protokol , který má infrastrukturu veřejného klíče, nikoli symetrický klíč . Protokol se používá pro autentizaci , generování klíčů, integritu dat a důvěrnost.
V září 1993 byla publikována první verze GSS-API [2] [3] a ve stejnou dobu se objevil mechanismus Kerberos V5 [4] . Ale zatímco Kerberos 5 se stal široce používaným a zavedeným protokolem v mnoha systémech, některé aplikace potřebovaly mít GSS-API postavené na infrastruktuře veřejného klíče spíše než na infrastruktuře symetrických klíčů. To vedlo k vytvoření protokolu SPKM (jeho první dvě varianty) v říjnu 1996 Carlisle Adams . Když však byl v roce 2000 vytvořen NFSv4 , vyvstal problém vzájemné autentizace a vytvoření zabezpečeného kanálu mezi anonymním uživatelem a serverem, což vedlo ke vzniku SPKM-3.
Z výše uvedených vlastností vyplývá, že SPKM má flexibilitu a funkčnost, bez zbytečné složitosti a implementační režie. Protože SPKM vyhovuje GSS-API, může být aplikací použit jako alternativní protokol pro zabezpečení sítě (například místo Kerberos) [6] .
Popis General Security Services Programming Interface (GSS-API), podle lze rozdělit do 2 částí [2] :
SPKM je příkladem druhého typu dokumentu, a proto se nazývá „mechanismus GSS-API“. Tento mechanismus zajišťuje ověřování, generování klíčů, integritu dat a důvěrnost dat v distribuovaných aplikacích online pomocí infrastruktury veřejných klíčů. SPKM lze použít jako náhradu za jakoukoli jinou aplikaci, která využívá bezpečnostní služby prostřednictvím volání GSS-API (například aplikace, která již používá Kerberos GSS-API). Použití infrastruktury veřejného klíče umožňuje použití elektronických podpisů k zachování nepopiratelnosti autorství při zasílání zpráv a také poskytuje další výhody, jako je škálovatelnost pro velké skupiny uživatelů.
Tokeny definované v SPKM jsou určeny pro použití aplikačními programy v souladu s operačním paradigmatem GSS-API [2] . Funguje to následujícím způsobem. GSS-API je obvykle voláno síťovým protokolem (nebo aplikací, která jej používá), aby bylo zajištěno spojení se službami ověřování, důvěrnosti a/nebo integrity dat. Při volání GSS-API protokol (aplikace) přijímá tokeny, které mu poskytuje jeho (místní) implementace GSS-API (tj. mechanismus GSS-API), a předává tokeny vzdálenému systému na adrese na druhém konci je token přijat a jeho další zpracování již probíhá vlastním mechanismem GSS-API. Samotné GSS-API tedy neposkytuje bezpečnostní služby, místo toho poskytuje rozhraní mezi aplikacemi a implementacemi (mechanismy) GSS-API. A ty zase poskytují rozhraní kompatibilní s GSS-API, což vám umožňuje vytvářet aplikace, které mohou pracovat s různými bezpečnostními mechanismy; umožňující výměnu mechanismů bez nutnosti přepisování aplikací.
Aby byla zajištěna alespoň minimální kompatibilita mezi různými implementacemi SPKM, byl jeden z algoritmů integrity stanoven jako povinný (POVINNÝ) a všechny ostatní algoritmy a příklady jsou volitelně podporovány různými implementacemi, některé algoritmy jsou také označeny jako doporučené (DOPORUČENÉ), toto je děláno pro zvýšení kompatibility [6] .
Protokol SPKM používá následující algoritmy:
Používá se k zajištění toho, že data nebyla změněna třetí stranou. V závislosti na algoritmu může také zajistit spolehlivost a nemožnost popření autorství zprávy.
Jako příklady lze použít následující algoritmy (identifikátory algoritmů jsou uvedeny níže):
md5WithRSAEencryption IDENTIFIKÁTOR OBJEKTU ::= { iso(1) člen-tělo(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 //vypůjčeno od PKCS#1 }Tento algoritmus je pro SPKM povinný (POVINNÝ). Zajišťuje integritu, autenticitu a nepopiratelnost dat pomocí výpočtu elektronického podpisu RSA založeného na hashovací funkci MD5 . Vzhledem k tomu, že tento algoritmus je v současné době jediným požadovaným algoritmem integrity a autentizace, bylo pro interoperabilitu také stanoveno, že md5WithRSA bude podepisovacím algoritmem pro všechny tokeny připojení, ve kterých je integrita kontrolována pomocí podpisu, a nikoli na základě MAC. Možná v budoucnu budou existovat další povinné algoritmy a pak tato podmínka kladená na markery zmizí [6] .
DES-MAC IDENTIFIKÁTOR OBJEKTU ::= { iso(1) identifikovaná-organizace(3) oiw(14) secsig(3) //ukládá délku MAC v bitech jako celé číslo, algorithm(2) 10 //omezeno na násobky 8, od 16 do 64 }Tento algoritmus se DOPORUČUJE a integrita je vynucována pomocí MAC založené na DES.
md5-DES-CBC IDENTIFIKÁTOR OBJEKTU ::= { iso(1) identifikovaná-organizace(3) dod(6) internet(1) bezpečnost(5) integrita(3) md5-DES-CBC(1) }Integrita dat je zde zajištěna šifrováním na bázi DES - CBC a „smíšeným“ MD5 hashováním. To je v praxi rychlejší než výpočet DES-MAC, pokud jsou vstupní data malá (řádově několik bajtů). Všimněte si, že bez hnětení je integrita mechanismu nanejvýš nebo rovna síle DES proti útoku známého otevřeného textu.
sum64-DES-CBC IDENTIFIKÁTOR OBJEKTU ::= { iso(1) identifikovaná-organizace(3) dod(6) internet(1) zabezpečení(5) integrita(3) sum64-DES-CBC(2) }Tento algoritmus zajišťuje integritu dat pomocí šifrování pomocí DES CBC. Zřetězení "smíšených" dat a součtu všech vstupních datových bloků (součet se vypočítá pomocí modulo 2 64 - 1 sčítání ). V tomto algoritmu je tedy šifrování nezbytnou podmínkou pro zajištění integrity dat [6] .
Tyto symetrické algoritmy se používají k šifrování dat pro volání GSS-API: gss_seal() / gss_wrap() .
Příklad:
DES-CBC IDENTIFIKÁTOR OBJEKTU ::= { iso(1) identifikovaná-organizace(3) oiw(14) secsig(3) algoritmus(2) 7 }Tento algoritmus se DOPORUČUJE.
Používá se k vytvoření symetrického klíče používaného uzly během připojení. Dále jsou z tohoto klíče vytvořeny podklíče pro algoritmy integrity a důvěrnosti. Generování klíčů probíhá během výměny ověřování X.509, takže výsledný symetrický klíč je ověřen.
Příklady:
RSAEncryption OBJECT IDENTIFIER ::= { iso(1) člen-tělo(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 // vypůjčeno z PKCS#1 a RFC-1423 }V tomto POVINNÉM algoritmu je klíč připojení vytvořen iniciátorem pomocí veřejného klíče RSA cíle a odeslán mu. Cíl zase nemusí být zodpovězen, aby mohl být vygenerován klíč.
dhKeyAgreement OBJECT IDENTIFIER ::= { iso(1) člen-tělo(2) US(840) rsadsi(113549) pkcs(1) pkcs-3(3) 1 }V tomto příkladu je klíč generován oběma uzly pomocí algoritmu Diffie-Hellman . Cíl tedy musí reagovat na iniciátor, aby mohl navázat spojení (proto tento algoritmus nelze použít s jednosměrnou autentizací v SPKM-2).
Generováním klíče spojení pomocí K-ALG musí uzly získat sadu podklíčů pro algoritmy důvěrnosti a integrity. K tomu se používají jednosměrné funkce . Nechť je seznam akceptovaných algoritmů ochrany soukromí očíslován postupně, to znamená, že prvnímu algoritmu (výchozímu algoritmu) je přiřazeno číslo 0, druhému je číslo 1 a tak dále. Nechť je seznam algoritmů integrity očíslován stejným způsobem. Nakonec nechť je spojovacím klíčem binární řetězec libovolné délky M , s výhradou omezení:
L ≤ M ≤ UBitová délka spojovacího klíče musí být větší než největší bitová délka podklíčů (C-ALG nebo I-ALG) a zároveň je shora ohraničena vstupními parametry algoritmu odvozování klíče ( K-ALG).
Například při použití DES a 3-DES v algoritmech ochrany soukromí a DES-MAC v algoritmu integrity musí mít spojovací klíč alespoň 112 bitů. A při použití 512bitového RSA je možná délka 424 bitů (největší povolený vstupní parametr RSAEncryption, popsaný v PKCS#1). Na druhou stranu, při použití algoritmu dhKeyAgreement je klíč připojení vypočítán algoritmem Diffie-Hellman (kromě vysokého bajtu, který je z bezpečnostních důvodů vyřazen), takže jeho délka bude o 8 bitů menší než p modul, což je přibližně 1000 bitů [6] .
Algoritmus pro získání k-bitového podklíče je definován takto:
rightmost_k_bits ( OWF ( context_key || x || n || s || context_key ) ) , kde:kontext_klíč - klíč připojení;
x - ASCII znak "C" (0x43) při vytváření podklíče pro algoritmus důvěrnosti, ASCII znak "I" (0x49) při vytváření podklíče pro algoritmus integrity;
n je číslo algoritmu v odpovídajícím seznamu povolených (ASCII znak "0" (0x30), "1" (0x31) atd.);
s - "fáze" zpracování - vždy se rovná ASCII znaku "0" (0x30), pokud "k" není větší než výstupní velikost jednosměrné funkce (OWF), v takovém případě je jednosměrná funkce přepočítáno se zvýšením hodnoty "stage" (každá výstupní hodnota OWF připojená na konec předchozích), dokud se nevytvoří "k" bitů;
|| - operace zřetězení;
OWF je odpovídající jednosměrná funkce.
Příklady:
MD5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5 }Tento algoritmus je povinný (POVINNÝ).
SHA OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 18 }Stávající hashovací funkce neodpovídají všem vlastnostem jednosměrných funkcí. Proto se během procesu navazování připojení používá vyjednávání algoritmu odvození podklíče, což umožňuje budoucí jednosměrná vylepšení funkcí vyjednávat se staršími verzemi.
V procesu navazování spojení v SPKM navrhne iniciátor řadu možných algoritmů důvěrnosti a integrity dat (včetně algoritmů elektronického podpisu). Přijímač zvolí, které algoritmy budou použity v navázaném spojení, a odešle zpět opravený seznam podporovaných algoritmů. Každá zpráva přenášená přes navázané spojení může používat jakýkoli algoritmus důvěrnosti a integrity, přičemž algoritmy uvedené na prvním místě v seznamu jsou výchozí. Algoritmy důvěrnosti a integrity přijaté pro dané připojení určují hodnoty parametru kvality ochrany ( Quality Of Protection ) používaného funkcemi gss_getMIC ( ) a gss_wrap () , které vypočítávají kódy integrity kryptografických zpráv a připojují je k zpráva. Pokud se neočekává žádná odpověď od příjemce (jednosměrná autentizace v SPKM-2), pak budou v procesu přenosu zprávy použity algoritmy nabízené zdrojem. Pokud přijímač nepodporuje použité algoritmy, odešle token pro ukončení připojení (smazat token) do zdroje a připojení je ukončeno.
Navíc v prvním tokenu navázání spojení původ navrhuje řadu možných algoritmů generování klíčů (K_ALG) spolu s klíčem (nebo polovinou klíče) odpovídajícímu prvnímu algoritmu v seznamu. Pokud tento algoritmus není přijatelný, musí si příjemce vybrat jeden ze zbývajících v seznamu a odeslat svůj výběr spolu s klíčem (polovinou) odpovídajícímu zvolenému algoritmu. Pokud seznam odeslaný do přijímače neobsahuje jím podporovaný algoritmus, odešle do zdroje značku odpojení. V případě potřeby (pokud přijímač zvolí dvoucestný algoritmus generování klíče, jako je tomu u algoritmu Diffie-Hellman), zdroj odešle svou polovinu klíče zpět do přijímače. Konečně v prvním tokenu navázání připojení zdroj nabízí řadu povolených algoritmů generování podklíčů, ale pokud se použije jednosměrná autentizace, nabídne se pouze jeden algoritmus. Algoritmus (jediný) zvolený příjemcem se stává algoritmem pro získání podklíče v navázaném spojení [6] .
Abychom pochopili, jak fungují tokeny používané v SPKM, podívejme se na příklad navázání spojení na základě náhodných čísel. Nebudeme se zabývat všemi dostupnými tokeny a funkcemi, pro seznámení s celým seznamem a pro zobrazení jejich popisu a implementace je lepší odkázat na RFC 2025 .
V zobrazeném diagramu iniciátor připojení volá funkci gss_init_sec_context() , která vrací token SPKM_REQ , který je poté odeslán do přijímače pomocí používaného síťového protokolu. Přijímač po obdržení tohoto tokenu jej předá gss_accept_sec_context() , který jako výsledek vrátí SPKM_REP_TI . Jeho přijímač jej pošle zpět iniciátorovi. To zase používá tuto značku jako vstupní parametr během druhého volání gss_init_sec_context() . Pokud iniciátor použil jednosměrnou autentizaci, pak zde navazování spojení končí. V opačném případě (například pokud je zpočátku vyžadována vzájemná autentizace), gss_init_sec_context() vrátí SPKM_REP_IT , které je odesláno příjemci. Použije tento token během druhého volání funkce gss_accept_sec_context() a tím dokončí nastavení připojení. Poté si strany mohou vyměňovat tokeny SPKM_MIC a SPKM_WRAP, dokud jedna ze stran nepošle SPKM_DEL k ukončení spojení [5] .
Značka SPKM_REQ obsahuje kromě jiných datových polí následující položky:
Integrita těchto dat je chráněna a jsou také podepsána elektronickým podpisem iniciátora připojení. Pokud si přál zůstat v anonymitě, v tomto případě je integrita chráněna pomocí MAC. Volitelně lze v tomto tokenu odesílat informace o digitálních certifikátech .
Značka SPKM_REP_TI obsahuje :
Integrita těchto dat je chráněna a jsou také podepsána elektronickým podpisem příjemce. Všimněte si, že náhodné číslo iniciátora podepsané přijímačem mu dává záruku, že přijímač je "živý" a spolehlivý. Informace o digitálních certifikátech mohou být zaslány v tomto tokenu, pokud o to iniciátor požádá v SPKM_REQ .
Pokud byla vybrána vzájemná autentizace, použije se token SPKM_REP_IT obsahující následující pole:
Integrita těchto dat je chráněna a jsou rovněž podepsána elektronickým podpisem iniciátora. Všimněte si, že náhodné číslo příjemce podepsané iniciátorem mu dává záruku, že iniciátor je „živý“ a spolehlivý.
Po dokončení navázání spojení s náhodným číslem jsou obě strany autentizovány (bez použití důvěryhodných časových razítek), klíč připojení byl bezpečně vytvořen, jsou odsouhlaseny dvě sady algoritmů (důvěrnost a integrita), které budou ve spojení používat. Operace MIC a WRAP . Každá značka SPKM_MIC , SPKM_WRAP a SPKM_DEL může explicitně specifikovat příslušný algoritmus z vyjednaného seznamu, který se má použít pro data spojená se značkou, nebo použít „výchozí“ algoritmy (tj. první algoritmy v každém ze seznamů).
SPKM_MIC – používá se pro podepisování a kontrolu integrity dat (gss_sign() / gss_getMIC())
SPKM_WRAP – používá se pro šifrování (dešifrování) a ochranu soukromí dat (gss_seal() / gss_wrap())
SPKM_DEL - pro ukončení spojení (gss_delete_sec_context()).
Značky proto obsahují následující informace:
Tento formát tokenu poskytuje větší flexibilitu při volání aplikací pro výběr kvality ochrany (QOP), která je vhodná pro chráněná data v rámci navázaného připojení [5] .
Původně byly popsány dvě varianty SPKM: SPKM-1 a SPKM-2, hlavní rozdíl je v tom, že SPKM-2 vyžaduje důvěryhodná časová razítka pro opětovné nalezení během navazování spojení, zatímco SPKM-1 nikoli. To poskytuje aplikacím větší flexibilitu, protože není vždy možné v systému používat důvěryhodná časová razítka. Když byl v roce 2000 vytvořen protokol NFSv4, vyvstala potřeba mechanismu, který zajistí vytvoření zabezpečeného kanálu se vzájemnou autentizací, kde:
Tak se objevil SPKM-3, který je pomocí doplňku LIPKEY základem provozu síťových souborových systémů [8] [9] . Především byl vytvořen pro zjednodušení postupu ověřování. Podívejme se na tento mechanismus podrobněji.
Klient:
Mezi klientem a serverem je tedy vytvořeno zabezpečené spojení, jak můžete vidět zde, je použit algoritmus Diffie-Hellman. Klient může poskytnout své přihlašovací jméno a heslo pro autentizaci (nebo certifikáty), není to však vyžadováno, to znamená, že klient může zůstat anonymní.
Jak vidíte, použitý autentizační mechanismus je podobný TLS, ale spolu s jednoduchostí a pohodlím zdědil i hlavní nevýhodu – možnost útoku typu man-in-the-middle [10] .
GSS-API ( Generic Security Service - Application Programming Interface - Generic Security Service - Application Programming Interface ) umožňuje aplikaci autentizovat uživatele odpovídajícího jiné aplikaci, aby mu byla udělena práva a u každé zprávy aplikovat služby zabezpečení důvěrnosti a integrity dat.
Existují 4 kroky při používání GSS-API:
| Protokoly ověřování a výměny klíčů | |
|---|---|
| Se symetrickými algoritmy | |
| Se symetrickými a asymetrickými algoritmy | |
| Protokoly a služby používané na internetu | |