Bajecny svet elektronickeho podpisu | online podpora stejnojmenne knihy z Edice CZ.NIC

8.2        Přihlašování

Dalším účelem, ke kterému se technologie elektronického podpisu používají, a to čím dál tím častěji, je potřeba identifikace a autentizace. Například při přihlašování uživatele k nějaké on-line službě, ale obecně všude tam, kde se jedna strana potřebuje představit druhé straně (říci kým je, neboli: identifikovat se) a současně prokázat, že je skutečně tím, za koho se vydává (autentizovat se, provést autentizaci).

Pro identifikaci a autentizaci samozřejmě existuje řada různých metod a technik, které jsou „různě silné“ ve smyslu své spolehlivosti a možnosti nějakého podvržení či podvodu. Historicky nejstarší, ale přesto stále používaná, je identifikace pomocí uživatelského jména a autentizace pomocí hesla. Ale snad netřeba podrobněji rozvádět, jak málo je tato varianta bezpečná. Jak snadné je někde odposlechnout či jen „odkouknout“ něčí jméno a heslo, a pak jej zneužít. 

Proto se stále častěji přechází na sofistikovanější metody autentizace (prokázání vlastní identity), které skýtají podstatně vyšší míru bezpečnosti a ochrany proti zneužití a podvodům. Tyto metody se obecně snaží „zapojit do hry“ co možná nejvíce dalších faktorů, které se pak spolupodílejí na autentizaci. Proto se v této souvislosti hovoří o vícefaktorové autentizaci.

Takovým dalším faktorem může být „něco, co uživatel právě drží“, resp. má ve své moci a může s tím nakládat. Což může být například soukromý klíč, kterým disponuje právě (a pouze) uživatel[4]. Proč jej tedy nevyužít ke zvýšení spolehlivosti a bezpečnosti autentizace? A s ním i certifikáty, které jsou se soukromým klíčem spojeny?

Způsob, jakým soukromý klíč „zapojit do hry“ i pro potřeby autentizace, je principiálně velmi jednoduchý a vychází ze základního principu asymetrické kryptografie, který jsme si již vícekrát popisovali: že soukromý klíč a veřejný klíč (obsažený v certifikátu) jsou „do páru“ a co lze „zamknout“ jedním z nich, lze „odemknout“ právě a pouze tím druhým. Navíc s vědomím toho, že soukromý klíč uživatel nesmí „dát z ruky“, a tak s ním může cokoli „uzamykat“ či naopak „odemykat“ jen u sebe. Naproti tomu svůj veřejný klíč (jako součást svého certifikátu) může předat protistraně, aby s ním mohla „odemykat“ či „zamykat“ ona.

Pak již zbývá jen vybrat si, který z klíčů bude použit dříve. V úvahu tedy připadají dva možné scénáře, ve kterých pro jednoduchost nazývejme přihlašujícího se uživatele klientem, a protistranu serverem:   

·         server pošle klientovi „něco“, co klient „uzamkne“ svým soukromým klíčem a vrátí serveru, spolu se svým certifikátem. Server využije veřejný klíč z certifikátu, a s ním „odemkne“ to, co mu klient vrátil.

·         klient nejprve pošle serveru svůj certifikát. Server využije veřejný klíč, který je v certifikátu obsažen, a s ním „uzamkne“ obdobné „něco“, co následně pošle klientovi. Ten toto „něco“ zase „odemkne“ pomocí svého soukromého klíče a odemčené vrátí zpět serveru.

Oba tyto scénáře implementují metodu, označovanou jako metoda výzvy a odpovědi (anglicky challenge-response): jedna strana pošle druhé „výzvu“, a ta na ni zareaguje svou „odpovědí“.

V případě prvního scénáře je touto výzvou nějaký (obvykle náhodný) „kus dat“, který server zašle klientovi. Klient jej podepíše, neboli opatří svým elektronickým podpisem (k čemuž potřebuje svůj soukromý klíč) a přidá ještě svůj certifikát. Tím vzniká odpověď, která se vrací serveru – a ten si ověří podpis pomocí veřejného klíče z certifikátu.

V případě druhého scénáře pak nejde o podepisování, ale o šifrování: server nejprve zašifruje svůj „kus dat“, a teprve tím vzniká výzva, kterou zašle klientovi. Ten ji musí správně dešifrovat (pomocí svého soukromého klíče), a pak vrátit serveru jako svou odpověď. Server si pak zkontroluje, zda se shoduje s původním „kusem dat“.

V praxi se dnes používá téměř výlučně první ze zde uváděných scénářů, jelikož má oproti tomu druhému některé významné přednosti. Například tu, že certifikát klienta (přihlašujícího se uživatele) není třeba posílat nějak „dopředu“ (aby mohl být využit při šifrování v rámci druhého scénáře), ale stačí jej poslat až spolu s odpovědí.

Samotnou výzvou (resp. “kusem dat“), která se posílá v rámci prvního scénáře, bývá v praxi nějaká náhodně generovaná hodnota, resp. řetězec bitů, doplněná o časový údaj (resp. časové razítko). To proto, aby se ještě více znesnadnilo případné zneužití a podvody.


[4] Další možností je využít „něco, co uživatel zná“ (například nějaké heslo, jednorázový kód apod.) či „něco, čím uživatel je“, jako například otisk jeho prstu, vzorek sítnice apod.



© Jiří Peterka, 2011, profil na Google+
Valid HTML 4.01 Transitional Ověřit CSS!
3A2E
5665
6E6F
7661
6E69
2E3A
0D0A
5475
746F
206B
6E69
6875
2076
656E
756A
6920
7376
6520
7A65
6E65
2049
7265
6E65
2C20
7379
6E6F
7669
204A
6972
696D
7520
6120
6463
6572
6920
4576
652E
0D0A
5620
5072
617A
652C
204C
5032
3031
3020
4A69
7269
2050
6574
6572
6B61