Համակարգում օգտվողների գրանցման և լիազորման համար Rutoken տեխնոլոգիայի օգտագործման փորձ (մաս 1)

Բարի օր Ես ուզում եմ կիսվել իմ փորձով այս թեմայի վերաբերյալ:

Rutoken- ը ապարատային եւ ծրագրային լուծումներ է վավերացման, տեղեկատվական անվտանգության եւ էլեկտրոնային ստորագրության ոլորտում: Ըստ էության, սա ֆլեշ կրիչ է, որը կարող է պահպանել վավերացման տվյալները, որոնք օգտագործողը օգտագործում է համակարգ մուտք գործելու համար:

Այս օրինակում օգտագործվում է Rutoken EDS 2.0:

Այս Rutoken-ի հետ աշխատելու համար ձեզ անհրաժեշտ է տեղադրել վարորդ Windows-ի վրա.

Windows- ի համար պարզապես մեկ վարորդ տեղադրելը ապահովում է, որ անհրաժեշտ է այն ամենը, ինչ անհրաժեշտ է, որպեսզի ՕՀ-ն տեսնի ձեր ռուոկեն եւ կարող է աշխատել դրա հետ:

Դուք կարող եք համագործակցել Rutoken-ի հետ տարբեր ձևերով: Դուք կարող եք մուտք գործել այն հավելվածի սերվերի կողմից կամ անմիջապես հաճախորդի կողմից: Այս օրինակը կանդրադառնա Rutoken-ի հետ փոխգործակցությանը հավելվածի հաճախորդի կողմից:

Հավելվածի հաճախորդային մասը փոխազդում է rutoken-ի հետ rutoken plugin-ի միջոցով: Սա ծրագիր է, որը տեղադրված է առանձին յուրաքանչյուր բրաուզերի վրա: Windows-ի համար պարզապես անհրաժեշտ է ներբեռնել և տեղադրել փլագինը, Գտնվում է այս հղումով.

Վերջ, այժմ մենք կարող ենք Rutoken-ի հետ շփվել հավելվածի հաճախորդի կողմից:

Այս օրինակը քննարկում է համակարգում օգտագործողի թույլտվության ալգորիթմի ներդրման գաղափարը՝ օգտագործելով մարտահրավեր-արձագանքման սխեմա:

Գաղափարի էությունը հետևյալն է.

1. Հաճախորդը թույլտվության հարցում է ուղարկում սերվերին:
2. Սերվերը պատասխանում է հաճախորդի խնդրանքին` ուղարկելով պատահական տող:
3. Հաճախորդը լրացնում է այս տողը պատահական 32 բիթով:
4. Հաճախորդը ստորագրում է ստացված տողը իր վկայականով:
5. Հաճախորդը ստացված գաղտնագրված հաղորդագրությունն ուղարկում է սերվերին:
6. Սերվերը ստուգում է ստորագրությունը՝ ստանալով բնօրինակ չգաղտնագրված հաղորդագրությունը:
7. Սերվերը կտրում է ստացված չգաղտնագրված հաղորդագրությունից վերջին 32 բիթերը:
8. Սերվերը ստացված արդյունքը համեմատում է հաղորդագրության հետ, որն ուղարկվել է թույլտվություն խնդրելիս:
9. Եթե ​​հաղորդագրությունները նույնն են, ապա թույլտվությունը համարվում է հաջողված:

Վերոնշյալ ալգորիթմում կա վկայագիր: Այս օրինակի համար դուք պետք է հասկանաք որոշ ծածկագրային տեսություն: Հաբրեի վրա կա հիանալի հոդված այս թեմայի վերաբերյալ.

Այս օրինակում մենք կօգտագործենք ասիմետրիկ գաղտնագրման ալգորիթմներ: Ասիմետրիկ ալգորիթմներ իրականացնելու համար դուք պետք է ունենաք բանալիների զույգ և վկայական:

Բանալիների զույգը բաղկացած է երկու մասից՝ մասնավոր և հանրային բանալի: Մասնավոր բանալին, ինչպես ցույց է տալիս նրա անունը, պետք է գաղտնի լինի: Մենք այն օգտագործում ենք տեղեկատվության վերծանման համար: Հանրային բանալին կարող է բաժանվել ցանկացածին: Այս բանալին օգտագործվում է տվյալների գաղտնագրման համար: Այսպիսով, ցանկացած օգտատեր կարող է գաղտնագրել տվյալները՝ օգտագործելով հանրային բանալին, բայց միայն մասնավոր բանալու սեփականատերը կարող է վերծանել այդ տեղեկատվությունը:

Վկայագիրը էլեկտրոնային փաստաթուղթ է, որը պարունակում է տեղեկատվություն այն օգտագործողի մասին, ում պատկանում է վկայագիրը, ինչպես նաև հանրային բանալին: Հավաստագրի միջոցով օգտատերը կարող է ստորագրել ցանկացած տվյալ և ուղարկել այն սերվերին, որը կարող է ստուգել ստորագրությունը և վերծանել տվյալները։

Հաղորդագրությունը վկայականով ճիշտ ստորագրելու համար անհրաժեշտ է այն ճիշտ ստեղծել: Դա անելու համար նախ Rutoken-ում ստեղծվում է բանալիների զույգ, այնուհետև վկայականը պետք է միացվի այս բանալիների զույգի հանրային բանալիին: Վկայագիրը պետք է ունենա հենց այն հանրային բանալին, որը գտնվում է Rutoken-ում, սա կարևոր է: Եթե ​​մենք պարզապես ստեղծենք բանալիների զույգ և վկայագիր անմիջապես հավելվածի հաճախորդի կողմից, ապա ինչպե՞ս կարող է սերվերը ապակոդավորել այս կոդավորված հաղորդագրությունը: Ի վերջո, նա ընդհանրապես ոչինչ չգիտի ո՛չ բանալիների զույգի, ո՛չ էլ վկայագրի մասին։

Եթե ​​դուք ավելի խորանաք այս թեմայի մեջ, կարող եք հետաքրքիր տեղեկություններ գտնել ինտերնետում: Կան որոշակի հավաստագրման մարմիններ, որոնց մենք ակնհայտորեն վստահում ենք: Այս սերտիֆիկացման մարմինները կարող են վկայականներ տրամադրել օգտվողներին, նրանք տեղադրում են այդ վկայագրերը իրենց սերվերում: Դրանից հետո, երբ հաճախորդը մուտք է գործում այս սերվերը, նա տեսնում է հենց այս վկայականը և տեսնում է, որ այն տրվել է սերտիֆիկացման մարմնի կողմից, ինչը նշանակում է, որ այս սերվերին կարելի է վստահել: Ինտերնետում նույնպես շատ տեղեկություններ կան այն մասին, թե ինչպես կարելի է ամեն ինչ ճիշտ կարգավորել: Օրինակ, դուք կարող եք սկսել այս.

Եթե ​​վերադառնանք մեր խնդրին, լուծումն ակնհայտ է թվում։ Դուք պետք է ինչ-որ կերպ ստեղծեք ձեր սեփական սերտիֆիկացման կենտրոնը: Բայց մինչ այդ պետք է պարզել, թե ինչի հիման վրա սերտիֆիկացման կենտրոնը պետք է վկայական տրամադրի օգտատիրոջը, քանի որ նա ոչինչ չգիտի այդ մասին։ (Օրինակ՝ նրա անունը, ազգանունը և այլն) Նման բան կա, որը կոչվում է վկայականի հարցում։ Այս ստանդարտի մասին լրացուցիչ տեղեկություններ կարելի է գտնել, օրինակ, Վիքիպեդիայում ru.wikipedia.org/wiki/PKCS
Մենք կօգտագործենք 1.7 տարբերակը՝ PKCS#10:

Եկեք նկարագրենք Rutoken-ում վկայագիր ստեղծելու ալգորիթմը (բնօրինակ աղբյուր. փաստաթղթերը):

1. Մենք ստեղծում ենք բանալիների զույգ հաճախորդի վրա և պահում այն ​​Rutoken-ում: (պահումը տեղի է ունենում ավտոմատ կերպով)
2. Մենք ստեղծում ենք սերտիֆիկատի հարցում հաճախորդի համար:
3. Հաճախորդից մենք այս հարցումն ուղարկում ենք սերվերին:
4. Երբ սերվերի վրա վկայական ստանալու հարցում ենք ստանում, մենք վկայական ենք տալիս մեր սերտիֆիկացման մարմնից:
5. Մենք այս վկայականն ուղարկում ենք հաճախորդին:
6. Մենք պահպանում ենք Rutoken վկայագիրը հաճախորդի վրա:
7. Վկայագիրը պետք է կապված լինի բանալիների զույգի հետ, որը ստեղծվել է առաջին քայլում:

Այժմ պարզ է դառնում, թե ինչպես սերվերը կկարողանա վերծանել հաճախորդի ստորագրությունը, քանի որ ինքն է վկայական տվել նրան։

Հաջորդ մասում մենք ավելի ուշադիր կանդրադառնանք, թե ինչպես ստեղծել ձեր վկայականի մարմինը `հիմնվելով բացվող բաց կոդով գերտոգրաֆիայի գրադարանի վրա:

Source: www.habr.com