Pokud by klic mohl byt pouze v nejakem HW, znamenalo by to, ze by si clovek musel poridit nejaky HW doplnek pocitace. Coz by samo o sobe asi nebylo tak hrozne. Tim ovsem vyvstavaji dalsi problemy - kam se bude pripojovat? S jakym OS a s jakym mailovym klientem bude pouzitelny?
Take by se musela resit moznost rozlusteni PIN hrubou silou (sezrani karty v bankomatu zde neprichazi v uvahu, dlouhy PIN si ale hur zapamatuju /navic zaruceny podpis asi budu pouzivat mene casto nez bankovni kartu =) pomalejsi refresh me pameti/, takze ho zapomenu nebo si ho nekam napisu a je po bezpecnosti).
Je treba myslet i obracene - cim vic budu klic chranit, tim slozitejsi bude i muj pristup k nemu, takze jej budu pouzivat jen v nezbytnych pripadech, tj. malo, tudiz se snizuje sance na vcasne zjisteni pripadne nezadouci manipulace s nim.
Periodicka zmena klice u CA me take moc nenadchava - bude to stat cas (osobni navsteva) a penize.
Ahoj Malviny, jeste jednou dik za namet tohoto clanku ... bez Tebe by s nejvetsi pravdepodobnosti nebyl. K prvni casti Tveho pripevku. Myslim, ze otazka s kym vsim budou spolupracovat jednotlive CA (PCS) bude zaviset pouze na smlouve mezi CA a vyrobcem OS. V tomto ale nevidim vetsi problem (Napada me tak snad jen jedna jedina spolecnost, ktera si mozna vytvori svou vlastni CA a tu pak bude povazovat za standart :-)).
K te druhe casti. TO uz je opravdu riziko toho ci onoho konkretniho uzivatele. Je to samozrejme otazka kolik je do ochrany sveho klice ochoten investovat (pripadne kolik se moznosti zneuziti takoveho klice obava). To ostatne souvisi i s posledni poznamkou ohledne periodicity vydavani noveho klice - i to je o bezpecnosti klice.
Hyml, vzdyt tu jsou obecne standardy pro technicka reseni bezpecnosti pres asymetrickou kryptografii.
Doporucuji prostudovat serii standardu PKCS na webu RSA.
Tam zjistite, ze existuje obecne rozhrani pro styk s ulozistem bezpecnostnich informaci (privatnich klicu a certifikatu), tzv. bezpecnostni token / Kryptoki - konkretne to je PKCS#11. Toto rozhrani definuje jak muzete vybirat vhodny certifikat, volit uroven bezpecnosti (silu pouziteho klice) apod.
Dalsi standardy zahrnuji format pozadavku na certifikat, samotny certifikat (X.509), pripadne zpusob prenosu privatniho klice mezi jednotlivymi bezpecnostnimi tokeny (PKCS#12) - ten se vzdy prenasi v zasifrovane forme s volenym heslem.
Diky teto silne standardizaci muzu vygenerovat privatni klic ve svem bezpecnostnim tokenu, vytvorit k nemu certificate request, ten predat certifikacni autorite, ktera mi vrati digitalni certifikat a ten ja naimportuji do sveho tokenu a rozeslu svym pa
...
Diky teto silne standardizaci muzu vygenerovat privatni klic ve svem bezpecnostnim tokenu, vytvorit k nemu certificate request, ten predat certifikacni autorite, ktera mi vrati digitalni certifikat a ten ja naimportuji do sveho tokenu a rozeslu svym partnerum. A to vse bez zavislosti mezi OS me aplikace a certifikacni autority.
Co se tyce pouziti tokenu plne souhlasim s panem Kotkem, ale s malou pripominkou, ze pan Malviny mel patrne na mysli prenositelnost daneho HW mezi ruznymi PC.
Protoze je cely certifikat ulozen v tokenu (a jeho tajna cast, tj. soukromy klic, jen a pouze v nem - k dispozici je HW, kde je i v nem generovan, tzn. ze jej nikdy neopusti), muze jej jeho majitel pouzit na ruznych PC.
Prikladem je iKey, coz je token, ktery se pripojuje na USB port. Podminkou pro jeho pouziti je tedy pritomnost USB portu na PC a maly ovladaci software, ktery umoznuje s iKey pracovat.
Podporovany klientsky software:
Netscape Communicator 4.0 a vyssi
MS IE 4.0 a vyssi
MS Outlook 98 a vyssi
MS Outlook Express
Entrust PKI 3.0 a vyssi
Vsechna PKI prostredi a aplikace podporujici standard PKCS#11 nebo standard MS CAPI
