Sperto pri uzado de Rutoken-teknologio por registri kaj rajtigi uzantojn en la sistemo (parto 1)

Bonan posttagmezon Mi volas kunhavigi mian sperton pri ĉi tiu temo.

Rutoken estas aparataro kaj programaro solvoj en la kampo de aŭtentigo, informa sekureco kaj elektronika subskribo. Esence, ĉi tio estas poŝmemoro, kiu povas stoki aŭtentigajn datumojn, kiujn la uzanto uzas por ensaluti en la sistemon.

En ĉi tiu ekzemplo, Rutoken EDS 2.0 estas uzata.

Por labori kun ĉi tiu Rutoken vi bezonas instali pelilon sur Windows.

Por Vindozo, instali nur unu pelilon certigas, ke ĉio necesa estas instalita por ke la OS vidu vian Rutoken kaj povu labori kun ĝi.

Vi povas interagi kun Rutoken en diversaj manieroj. Vi povas aliri ĝin de la servila flanko de la aplikaĵo, aŭ rekte de la klienta flanko. Ĉi tiu ekzemplo rigardos interagon kun Rutoken de la klienta flanko de la aplikaĵo.

La klienta parto de la aplikaĵo interagas kun la rutoken per la rutoken kromaĵo. Ĉi tio estas programo kiu estas instalita aparte en ĉiu retumilo. Por Vindozo vi nur bezonas elŝuti kaj instali la kromprogramon, troviĝas ĉe ĉi tiu ligilo.

Jen ĝi, nun ni povas interagi kun Rutoken de la klienta flanko de la aplikaĵo.

Ĉi tiu ekzemplo diskutas la ideon efektivigi uzantan rajtigan algoritmon en la sistemo uzante la defio-respondan skemon.

La esenco de la ideo estas kiel sekvas:

1. La kliento sendas rajtigan peton al la servilo.
2. La servilo respondas al peto de la kliento sendante hazardan ĉenon.
3. La kliento plenigas ĉi tiun ŝnuron per hazardaj 32 bitoj.
4. La kliento subskribas la ricevitan ŝnuron per sia atestilo.
5. La kliento sendas la ricevitan ĉifritan mesaĝon al la servilo.
6. La servilo kontrolas la subskribon ricevante la originan neĉifritan mesaĝon.
7. La servilo forigas la lastajn 32 bitojn de la ricevita neĉifrita mesaĝo.
8. La servilo komparas la ricevitan rezulton kun la mesaĝo kiu estis sendita dum petado de rajtigo.
9. Se la mesaĝoj estas la samaj, tiam rajtigo estas konsiderata sukcesa.

En la ĉi-supra algoritmo ekzistas tia afero kiel atestilo. Por ĉi tiu ekzemplo, vi devas kompreni iun kriptografian teorion. Sur Habré estas bonega artikolo pri ĉi tiu temo.

En ĉi tiu ekzemplo, ni uzos nesimetriajn ĉifradajn algoritmojn. Por efektivigi nesimetriajn algoritmojn, vi devas havi ŝlosilparon kaj atestilon.

Ŝlosilparo konsistas el du partoj: privata ŝlosilo kaj publika ŝlosilo. La privata ŝlosilo, kiel ĝia nomo sugestas, devas esti sekreta. Ni uzas ĝin por deĉifri informojn. La publika ŝlosilo povas esti distribuita al iu ajn. Ĉi tiu ŝlosilo estas uzata por ĉifri datumojn. Tiel, ĉiu uzanto povas ĉifri datumojn uzante la publikan ŝlosilon, sed nur la posedanto de la privata ŝlosilo povas deĉifri ĉi tiun informon.

Atestilo estas elektronika dokumento, kiu enhavas informojn pri la uzanto, kiu posedas la atestilon, kaj ankaŭ publikan ŝlosilon. Kun atestilo, la uzanto povas subskribi ajnajn datumojn kaj sendi ĝin al la servilo, kiu povas kontroli la subskribon kaj deĉifri la datumojn.

Por ĝuste subskribi mesaĝon per atestilo, vi devas ĝuste krei ĝin. Por fari tion, ŝlosilparo unue estas kreita sur Rutoken, kaj tiam atestilo devas esti ligita al la publika ŝlosilo de ĉi tiu ŝlosilparo. La atestilo devas havi ĝuste la publikan ŝlosilon, kiu troviĝas sur Rutoken, ĉi tio estas grava. Se ni simple kreas ŝlosilparon kaj atestilon tuj ĉe la klienta flanko de la aplikaĵo, kiel tiam la servilo povas deĉifri ĉi tiun ĉifritan mesaĝon? Ja li tute nenion scias pri la ŝlosilparo aŭ pri la atestilo.

Se vi pliprofundiĝas en ĉi tiu temo, vi povas trovi interesajn informojn en la interreto. Estas certaj atestadaj aŭtoritatoj, kiujn ni evidente fidas. Ĉi tiuj atestadaj aŭtoritatoj povas eldoni atestilojn al uzantoj; ili instalas ĉi tiujn atestilojn sur sia servilo. Post tio, kiam la kliento aliras ĉi tiun servilon, li vidas ĉi tiun atestilon, kaj vidas, ke ĝi estis eldonita de atestadaŭtoritato, kio signifas, ke ĉi tiu servilo povas esti fidinda. Estas ankaŭ multe da informoj en la Interreto pri kiel agordi ĉion ĝuste. Ekzemple, vi povas komenci per ĉi tio.

Se ni revenos al nia problemo, la solvo ŝajnas evidenta. Vi devas iel krei vian propran atestan centron. Sed antaŭ tio, vi devas eltrovi sur kia bazo la atestadcentro devus doni atestilon al la uzanto, ĉar li scias nenion pri ĝi. (Ekzemple lia antaŭnomo, familia nomo, ktp.) Estas tia afero nomata atestilpeto. Pli da informoj pri ĉi tiu normo troveblas, ekzemple, en Vikipedio ru.wikipedia.org/wiki/PKCS
Ni uzos version 1.7 - PKCS#10.

Ni priskribu la algoritmon por generi atestilon pri Rutoken (origina fonto: dokumentado):

1. Ni kreas ŝlosilan paron sur la kliento kaj konservas ĝin sur Rutoken. (ŝparo okazas aŭtomate)
2. Ni kreas atestilpeton pri la kliento.
3. De la kliento ni sendas ĉi tiun peton al la servilo.
4. Kiam ni ricevas peton por atestilo en la servilo, ni emisias atestilon de nia atestadaŭtoritato.
5. Ni sendas ĉi tiun atestilon al la kliento.
6. Ni konservas la Rutoken-atestilon ĉe la kliento.
7. La atestilo devas esti ligita al la ŝlosila paro kiu estis kreita en la unua paŝo.

Nun evidentiĝas kiel la servilo povos malĉifri la subskribon de la kliento, ĉar ĝi mem elsendis la atestilon al li.

En la sekva parto, ni rigardos pli detale kiel agordi vian atestan aŭtoritaton surbaze de la plenrajta malfermfonta kriptografia biblioteko openSSL.

fonto: www.habr.com