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.