Goeie middag Ek wil my ervaring oor hierdie onderwerp deel.
Rutoken is hardeware- en sagteware-oplossings op die gebied van verifikasie, inligtingsekuriteit en elektroniese handtekening. In wese is dit 'n flash drive wat verifikasie data kan stoor wat die gebruiker gebruik om by die stelsel aan te meld.
In hierdie voorbeeld word Rutoken EDS 2.0 gebruik.
Om met hierdie Rutoken te werk, benodig jy.
Vir Windows, die installering van net een drywer verseker dat alles wat nodig is geïnstalleer is sodat die bedryfstelsel jou Rutoken sien en daarmee kan werk.
Jy kan op verskeie maniere met Rutoken kommunikeer. U kan toegang daartoe verkry vanaf die bedienerkant van die toepassing, of direk vanaf die kliëntkant. Hierdie voorbeeld sal kyk na interaksie met Rutoken vanaf die kliëntkant van die toepassing.
Die kliëntdeel van die toepassing is in wisselwerking met die rutoken deur die rutoken-inprop. Dit is 'n program wat afsonderlik op elke blaaier geïnstalleer word. Vir Windows moet jy net die inprop aflaai en installeer, .
Dit is dit, nou kan ons met Rutoken kommunikeer vanaf die kliëntkant van die toepassing.
Hierdie voorbeeld bespreek die idee om 'n gebruikersmagtigingsalgoritme in die stelsel te implementeer deur die uitdaging-reaksie-skema te gebruik.
Die kern van die idee is soos volg:
- Die kliënt stuur 'n magtigingsversoek na die bediener.
- Die bediener reageer op 'n versoek van die kliënt deur 'n ewekansige string te stuur.
- Die kliënt vul hierdie string met ewekansige 32 bisse.
- Die kliënt teken die ontvangde string met sy sertifikaat.
- Die kliënt stuur die ontvang geënkripteerde boodskap na die bediener.
- Die bediener verifieer die handtekening deur die oorspronklike ongeënkripteerde boodskap te ontvang.
- Die bediener stroop die laaste 32 bisse van die ontvangde ongeënkripteerde boodskap.
- Die bediener vergelyk die ontvangde resultaat met die boodskap wat gestuur is toe magtiging versoek is.
- As die boodskappe dieselfde is, word magtiging as suksesvol beskou.
In die bogenoemde algoritme is daar iets soos 'n sertifikaat. Vir hierdie voorbeeld moet jy een of ander kriptografiese teorie verstaan. Op Habré is daar .
In hierdie voorbeeld sal ons asimmetriese enkripsiealgoritmes gebruik. Om asimmetriese algoritmes te implementeer, moet jy 'n sleutelpaar en 'n sertifikaat hê.
'n Sleutelpaar bestaan uit twee dele: 'n private sleutel en 'n publieke sleutel. Die private sleutel, soos die naam aandui, moet geheim wees. Ons gebruik dit om inligting te dekripteer. Die publieke sleutel kan aan enigiemand versprei word. Hierdie sleutel word gebruik om data te enkripteer. Dus, enige gebruiker kan data enkripteer deur die publieke sleutel te gebruik, maar slegs die eienaar van die private sleutel kan hierdie inligting dekripteer.
'n Sertifikaat is 'n elektroniese dokument wat inligting bevat oor die gebruiker wat die sertifikaat besit, sowel as 'n publieke sleutel. Met 'n sertifikaat kan die gebruiker enige data teken en dit na die bediener stuur, wat die handtekening kan verifieer en die data kan dekripteer.
Om 'n boodskap korrek met 'n sertifikaat te onderteken, moet jy dit korrek skep. Om dit te doen, word 'n sleutelpaar eers op Rutoken geskep, en dan moet 'n sertifikaat aan die publieke sleutel van hierdie sleutelpaar gekoppel word. Die sertifikaat moet presies die publieke sleutel hê wat op Rutoken geleë is, dit is belangrik. As ons bloot 'n sleutelpaar en 'n sertifikaat onmiddellik aan die kliëntkant van die toepassing skep, hoe kan die bediener dan hierdie geënkripteerde boodskap dekripteer? Hy weet immers glad niks van óf die sleutelpaar óf die sertifikaat nie.
As jy dieper in hierdie onderwerp duik, kan jy interessante inligting op die internet vind. Daar is sekere sertifiseringsowerhede wat ons natuurlik vertrou. Hierdie sertifiseringsowerhede kan sertifikate aan gebruikers uitreik; hulle installeer hierdie sertifikate op hul bediener. Hierna, wanneer die kliënt toegang tot hierdie bediener verkry, sien hy hierdie einste sertifikaat, en sien dat dit deur 'n sertifiseringsowerheid uitgereik is, wat beteken dat hierdie bediener vertrou kan word. Daar is ook baie inligting op die internet oor hoe om alles reg op te stel. .
As ons terugkeer na ons probleem, lyk die oplossing voor die hand liggend. Jy moet op een of ander manier jou eie sertifiseringsentrum skep. Maar voor dit moet jy uitvind op watter basis die sertifiseringsentrum 'n sertifikaat aan die gebruiker moet uitreik, want hy weet niks daarvan nie. (Byvoorbeeld sy voornaam, van, ens.) Daar is so iets wat 'n sertifikaatversoek genoem word. Meer inligting oor hierdie standaard kan byvoorbeeld op Wikipedia gevind word
Ons sal weergawe 1.7 - PKCS#10 gebruik.
Kom ons beskryf die algoritme vir die generering van 'n sertifikaat op Rutoken (oorspronklike bron: ):
- Ons skep 'n sleutelpaar op die kliënt en stoor dit op Rutoken. (stoor vind outomaties plaas)
- Ons skep 'n sertifikaatversoek op die kliënt.
- Van die kliënt af stuur ons hierdie versoek na die bediener.
- Wanneer ons 'n versoek vir 'n sertifikaat op die bediener ontvang, reik ons 'n sertifikaat van ons sertifiseringsowerheid uit.
- Ons stuur hierdie sertifikaat aan die kliënt.
- Ons stoor die Rutoken-sertifikaat op die kliënt.
- Die sertifikaat moet gebind wees aan die sleutelpaar wat in die eerste stap geskep is.
Nou word dit duidelik hoe die bediener die kliënt se handtekening sal kan dekripteer, aangesien dit self die sertifikaat aan hom uitgereik het.
In die volgende deel sal ons nader kyk na hoe om u sertifikaatowerheid op te stel gebaseer op die volwaardige oopbron-kriptografie-biblioteek openSSL.
Bron: will.com