Goedemiddag! Ik wil graag mijn ervaring over dit onderwerp delen.
RUTOKEN zijn hardware- en softwareoplossingen op het gebied van authenticatie, informatiebeveiliging en digitale handtekeningen. In feite is het een USB-stick die authentificatiegegevens kan opslaan die gebruikers gebruiken om in het systeem in te loggen.
In dit voorbeeld wordt RUTOKEN ECP 2.0 gebruikt.
Voor het werken met deze RUTOKEN is het noodzakelijk.
Voor Windows zorgt de installatie van alleen de driver ervoor dat het besturingssysteem uw RUTOKEN herkent en ermee kan werken.
Met RUTOKEN kan op verschillende manieren worden samengewerkt. Toegang kan worden verkregen vanuit de serverzijde van de applicatie, of rechtstreeks vanuit de clientzijde. In dit voorbeeld zal de interactie met RUTOKEN vanuit de clientzijde van de applicatie worden besproken.
De clientzijde van de applicatie communiceert met de RUTOKEN via de RUTOKEN-plugin. Dit is een programma dat afzonderlijk op elke browser wordt geĆÆnstalleerd. Voor Windows is het voldoende om de plugin te downloaden en te installeren, .
Dat is het, nu kunnen we communiceren met RUTOKEN vanuit de clientzijde van de applicatie.
In dit voorbeeld wordt het idee van de implementatie van een gebruikersauthenticatie-algoritme in het systeem met behulp van het challenge-response-schema besproken.
De essentie van het idee is als volgt:
- De client stuurt een verzoek om autorisatie naar de server.
- De server stuurt als antwoord op het verzoek van de client een willekeurige tekenreeks.
- De client voegt aan deze tekenreeks 32 willekeurige bits toe.
- De client ondertekent de ontvangen tekenreeks met zijn certificaat.
- De client stuurt het gecodeerde bericht naar de server.
- De server controleert de handtekening en verkrijgt het oorspronkelijke ongecodeerde bericht.
- De server scheidt de laatste 32 bits van het ontvangen ongecodeerde bericht.
- De server vergelijkt het verkregen resultaat met het bericht dat bij het verzoek om autorisatie is verzonden.
- Als de berichten identiek zijn, wordt de autorisatie als succesvol beschouwd.
In het bovenstaande algoritme komt een concept als certificaat voor. In dit voorbeeld moet men enige cryptografische theorie begrijpen. Op Habra is er .
In dit voorbeeld zullen we asymmetrische encryptie-algoritmes gebruiken. Voor de implementatie van asymmetrische algoritmes is een sleutelparen en een certificaat vereist.
Een sleutelpaar bestaat uit twee delen: een privƩsleutel en een publieke sleutel. De privƩsleutel, zoals de naam al aangeeft, moet geheim blijven. Deze gebruiken we voor het ontsleutelen van informatie. De publieke sleutel kan aan iedereen worden verstrekt. Deze sleutel wordt gebruikt voor het versleutelen van gegevens. Op deze manier kan elke gebruiker gegevens versleutelen met behulp van de publieke sleutel, maar alleen de eigenaar van de privƩsleutel kan deze informatie ontsleutelen.
Een certificaat is een elektronisch document dat informatie bevat over de gebruiker die het certificaat bezit, evenals de publieke sleutel. Met een certificaat kan de gebruiker gegevens ondertekenen en deze naar de server verzenden, die deze handtekening kan verifiƫren en de gegevens kan ontsleutelen.
Om een bericht correct met een certificaat te kunnen ondertekenen, moet het certificaat op de juiste manier worden aangemaakt. Hiervoor wordt eerst een sleutelpaar op de Rux-token aangemaakt, waarna het certificaat aan de publieke sleutel van dit sleutelpaar moet worden gekoppeld. Het certificaat moet precies de publieke sleutel hebben die op de Rux-token staat, dit is belangrijk. Als we gewoon een sleutelpaar en certificaat direct op de clientzijde van de applicatie aanmaken, hoe kan de server dan later dit versleutelde bericht ontsleutelen? Immers, deze weet helemaal niets over het sleutelpaar of het certificaat.
Als we dieper op dit onderwerp ingaan, kunnen we interessante informatie op het internet vinden. Er zijn bepaalde certificeringsinstanties die we vertrouwen. Deze certificeringsinstanties kunnen certificaten aan gebruikers verstrekken en plaatsen deze certificaten op hun server. Wanneer een cliƫnt vervolgens deze server benadert, ziet hij dit certificaat en merkt hij dat het is uitgegeven door een certificeringsinstantie, wat betekent dat deze server betrouwbaar is. Meer informatie over hoe alles correct in te stellen is ook volop beschikbaar op het internet. .
Als we terugkijken naar onze taak, lijkt de oplossing voor de hand liggend. We moeten op de een of andere manier onze eigen certificeringsautoriteit opzetten. Maar voordat we dat doen, moeten we begrijpen op basis waarvan de certificeringsautoriteit een certificaat aan de gebruiker moet verstrekken, want hij weet er niks van. (Bijvoorbeeld zijn voornaam, achternaam, enzovoorts.) Er is zo'n ding dat wordt genoemd een certificaatverzoek. Meer over deze standaard kun je bijvoorbeeld op Wikipedia bekijken.
We gaan versie 1.7 gebruiken ā PKCS#10.
Laten we het algoritme voor het genereren van een certificaat op de RuToken beschrijven (oorspronkelijke bron ā ):
- Op de client creƫren we een sleutelpaar en slaan we dit op op de RuToken. (opslaan gebeurt automatisch)
- Op de client creƫren we een certificaatverzoek.
- We verzenden dit verzoek vanaf de client naar de server.
- Bij ontvangst van het certificaatverzoek op de server, verstrekken we een certificaat met onze eigen certificeringsautoriteit.
- We sturen dit certificaat naar de client.
- Op de client slaan we het certificaat op de RuToken op.
- Het certificaat moet worden gekoppeld aan het sleutelpaar dat in de eerste stap is aangemaakt.
Nu is het duidelijk hoe de server de handtekening van de client kan ontcijferen, aangezien hij zelf het certificaat heeft uitgegeven.
In het volgende deel zullen we in detail bekijken hoe we onze eigen certificeringsautoriteit kunnen configureren op basis van de volledige opensource cryptografische bibliotheek openSSL.
Bron: habr.com
