Kokemus Rutoken-teknologian käytöstä käyttäjien rekisteröinnissä ja valtuutuksessa järjestelmään (osa 1)

Hyvää iltapäivää Haluan jakaa kokemukseni tästä aiheesta.

Rutoken on laitteisto- ja ohjelmistoratkaisuja autentikoinnin, tietoturvan ja sähköisen allekirjoituksen alalla. Pohjimmiltaan tämä on flash-asema, joka voi tallentaa todennustietoja, joita käyttäjä käyttää kirjautuessaan järjestelmään.

Tässä esimerkissä käytetään Rutoken EDS 2.0:aa.

Tarvitset työskennelläksesi tämän Rutokenin kanssa asenna ohjain windowsiin.

Windowsissa vain yhden ohjaimen asentaminen varmistaa, että kaikki tarvittava on asennettu, jotta käyttöjärjestelmä näkee Rutokenin ja voi toimia sen kanssa.

Voit olla vuorovaikutuksessa Rutokenin kanssa monin eri tavoin. Voit käyttää sitä sovelluksen palvelinpuolelta tai suoraan asiakaspuolelta. Tässä esimerkissä tarkastellaan vuorovaikutusta Rutokenin kanssa sovelluksen asiakaspuolelta.

Sovelluksen asiakasosa on vuorovaikutuksessa rutokenin kanssa rutoken-laajennuksen kautta. Tämä on ohjelma, joka asennetaan erikseen jokaiseen selaimeen. Windowsille sinun tarvitsee vain ladata ja asentaa laajennus, löytyy tästä linkistä.

Siinä kaikki, nyt voimme olla vuorovaikutuksessa Rutokenin kanssa sovelluksen asiakaspuolelta.

Tämä esimerkki käsittelee ajatusta käyttäjän valtuutusalgoritmin toteuttamisesta järjestelmään käyttämällä haaste-vastaus -mallia.

Idean ydin on seuraava:

  1. Asiakas lähettää valtuutuspyynnön palvelimelle.
  2. Palvelin vastaa asiakkaan pyyntöön lähettämällä satunnaisen merkkijonon.
  3. Asiakas täyttää tämän merkkijonon satunnaisella 32 bitillä.
  4. Asiakas allekirjoittaa vastaanotetun merkkijonon varmentellaan.
  5. Asiakas lähettää vastaanotetun salatun viestin palvelimelle.
  6. Palvelin vahvistaa allekirjoituksen vastaanottamalla alkuperäisen salaamattoman viestin.
  7. Palvelin poistaa viimeiset 32 ​​bittiä vastaanotetusta salaamattomasta viestistä.
  8. Palvelin vertaa saatua tulosta valtuutusta pyydettäessä lähetettyyn viestiin.
  9. Jos viestit ovat samat, valtuutus katsotaan onnistuneeksi.

Yllä olevassa algoritmissa on sellainen asia kuin varmenne. Tätä esimerkkiä varten sinun on ymmärrettävä jonkin verran kryptografista teoriaa. Habrella on loistava artikkeli tästä aiheesta.

Tässä esimerkissä käytämme epäsymmetrisiä salausalgoritmeja. Epäsymmetristen algoritmien toteuttamiseksi sinulla on oltava avainpari ja varmenne.

Avainpari koostuu kahdesta osasta: yksityisestä avaimesta ja julkisesta avaimesta. Yksityisen avaimen on nimensä mukaisesti oltava salainen. Käytämme sitä tietojen salauksen purkamiseen. Julkinen avain voidaan jakaa kenelle tahansa. Tätä avainta käytetään tietojen salaamiseen. Siten kuka tahansa käyttäjä voi salata tiedot julkisella avaimella, mutta vain yksityisen avaimen omistaja voi purkaa tämän tiedon salauksen.

Varmenne on sähköinen asiakirja, joka sisältää tiedot varmenteen omistavasta käyttäjästä sekä julkisen avaimen. Varmenteen avulla käyttäjä voi allekirjoittaa minkä tahansa tiedon ja lähettää sen palvelimelle, joka voi tarkistaa allekirjoituksen ja purkaa tietojen salauksen.

Jotta voit allekirjoittaa viestin oikein varmenteella, sinun on luotava se oikein. Tätä varten Rutokeniin luodaan ensin avainpari, jonka jälkeen varmenne on linkitettävä tämän avainparin julkiseen avaimeen. Varmenteessa on oltava täsmälleen se julkinen avain, joka sijaitsee Rutokenissa, tämä on tärkeää. Jos luomme yksinkertaisesti avainparin ja varmenteen välittömästi sovelluksen asiakaspuolelle, kuinka palvelin sitten voi purkaa tämän salatun viestin? Loppujen lopuksi hän ei tiedä mitään avainparista eikä varmenteesta.

Jos sukeltat syvemmälle tähän aiheeseen, voit löytää mielenkiintoista tietoa Internetistä. On tiettyjä sertifiointiviranomaisia, joihin luonnollisesti luotamme. Nämä varmentajat voivat myöntää varmenteita käyttäjille ja asentaa nämä varmenteet palvelimelleen. Tämän jälkeen, kun asiakas käyttää tätä palvelinta, hän näkee juuri tämän varmenteen ja näkee, että sen on myöntänyt varmenneviranomainen, mikä tarkoittaa, että tähän palvelimeen voi luottaa. Internetissä on myös paljon tietoa siitä, kuinka kaikki asetetaan oikein. Voit esimerkiksi aloittaa tästä.

Jos palaamme ongelmaamme, ratkaisu näyttää ilmeiseltä. Sinun täytyy jotenkin luoda oma sertifiointikeskus. Mutta ennen sitä sinun on selvitettävä, millä perusteella varmennekeskuksen pitäisi antaa sertifikaatti käyttäjälle, koska hän ei tiedä siitä mitään. (Esimerkiksi hänen etunimensä, sukunimensä jne.) On olemassa sellainen asia, jota kutsutaan varmennepyynnöksi. Lisätietoja tästä standardista löytyy esimerkiksi Wikipediasta ru.wikipedia.org/wiki/PKCS
Käytämme versiota 1.7 - PKCS#10.

Kuvataan algoritmi varmenteen luomiseksi Rutokenissa (alkuperäinen lähde: dokumentointi):

  1. Luomme asiakkaalle avainparin ja tallennamme sen Rutokeniin. (tallennus tapahtuu automaattisesti)
  2. Luomme asiakkaalle varmennepyynnön.
  3. Asiakkaalta lähetämme tämän pyynnön palvelimelle.
  4. Kun saamme varmennepyynnön palvelimelle, annamme varmenteen varmenneviranomaiselta.
  5. Lähetämme tämän todistuksen asiakkaalle.
  6. Tallennamme Rutoken-varmenteen asiakkaalle.
  7. Varmenne on sidottava ensimmäisessä vaiheessa luotuun avainpariin.

Nyt käy selväksi, kuinka palvelin pystyy purkamaan asiakkaan allekirjoituksen salauksen, koska se itse myönsi varmenteen hänelle.

Seuraavassa osassa tarkastellaan lähemmin varmenneviranomaisen määrittämistä täysimittaisen avoimen lähdekoodin salauskirjaston openSSL:n perusteella.

Lähde: will.com

Lisää kommentti