Goedemiddag Ik wil mijn ervaring over dit onderwerp delen.
Rutoken is hardware- en softwareoplossingen op het gebied van authenticatie, informatiebeveiliging en elektronische handtekening. In wezen is dit een flashstation waarop authenticatiegegevens kunnen worden opgeslagen die de gebruiker gebruikt om in te loggen op het systeem.
In dit voorbeeld wordt Rutoken EDS 2.0 gebruikt.
Om met deze Rutoken te werken heb je nodig.
Voor Windows zorgt het installeren van slechts één stuurprogramma ervoor dat alles wat nodig is, wordt geïnstalleerd, zodat het besturingssysteem uw Rutoken ziet en ermee kan werken.
Je kunt op verschillende manieren met Rutoken communiceren. U kunt er toegang toe krijgen vanaf de serverzijde van de applicatie, of rechtstreeks vanaf de clientzijde. In dit voorbeeld wordt gekeken naar de interactie met Rutoken vanaf de clientzijde van de applicatie.
Het clientgedeelte van de applicatie communiceert met de rutoken via de rutoken-plug-in. Dit is een programma dat in elke browser afzonderlijk wordt geïnstalleerd. Voor Windows hoeft u alleen maar de plug-in te downloaden en te installeren, .
Dat is alles, nu kunnen we met Rutoken communiceren vanaf de clientzijde van de applicatie.
Dit voorbeeld bespreekt het idee van het implementeren van een gebruikersautorisatie-algoritme in het systeem met behulp van het challenge-response-schema.
De essentie van het idee is als volgt:
- De client stuurt een autorisatieverzoek naar de server.
- De server reageert op een verzoek van de client door een willekeurige reeks te verzenden.
- De client vult deze string op met willekeurige 32 bits.
- De client ondertekent de ontvangen string met zijn certificaat.
- De client stuurt het ontvangen gecodeerde bericht naar de server.
- De server verifieert de handtekening door het originele, niet-gecodeerde bericht te ontvangen.
- De server verwijdert de laatste 32 bits uit het ontvangen ongecodeerde bericht.
- De server vergelijkt het ontvangen resultaat met het bericht dat is verzonden bij het aanvragen van autorisatie.
- Als de berichten hetzelfde zijn, wordt de autorisatie als succesvol beschouwd.
In het bovenstaande algoritme bestaat er zoiets als een certificaat. Voor dit voorbeeld moet je enige cryptografische theorie begrijpen. Op Habré wel .
In dit voorbeeld gebruiken we asymmetrische versleutelingsalgoritmen. Om asymmetrische algoritmen te implementeren, hebt u een sleutelpaar en een certificaat nodig.
Een sleutelpaar bestaat uit twee delen: een private sleutel en een publieke sleutel. De privésleutel moet, zoals de naam al doet vermoeden, geheim zijn. We gebruiken het om informatie te decoderen. De publieke sleutel kan aan iedereen worden gedistribueerd. Deze sleutel wordt gebruikt om gegevens te versleutelen. Elke gebruiker kan dus 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 eigenaar is van het certificaat, evenals een openbare sleutel. Met een certificaat kan de gebruiker alle gegevens ondertekenen en naar de server sturen, die de handtekening kan verifiëren en de gegevens kan decoderen.
Om een bericht correct te ondertekenen met een certificaat, moet u het correct aanmaken. Hiervoor wordt eerst een sleutelpaar aangemaakt op Rutoken, en vervolgens moet er een certificaat gekoppeld worden aan de publieke sleutel van dit sleutelpaar. Het certificaat moet exact de publieke sleutel hebben die op Rutoken staat, dit is belangrijk. Als we eenvoudigweg een sleutelpaar en een certificaat direct aan de clientzijde van de applicatie aanmaken, hoe kan de server dit gecodeerde bericht dan ontsleutelen? Hij weet immers helemaal niets van het sleutelpaar of het certificaat.
Als je dieper in dit onderwerp duikt, kun je interessante informatie op internet vinden. Er zijn bepaalde certificeringsinstanties die we uiteraard vertrouwen. Deze certificeringsinstanties kunnen certificaten uitgeven aan gebruikers; zij installeren deze certificaten op hun server. Wanneer de cliënt hierna toegang krijgt tot deze server, ziet hij dit certificaat en ziet hij dat het is uitgegeven door een certificeringsinstantie, wat betekent dat deze server kan worden vertrouwd. Ook op internet is voldoende informatie te vinden over hoe je alles correct instelt. .
Als we terugkeren naar ons probleem, lijkt de oplossing voor de hand liggend. U moet op de een of andere manier uw eigen certificeringscentrum creëren. Maar daarvoor moet u uitzoeken op welke basis het certificeringscentrum een certificaat aan de gebruiker moet afgeven, omdat hij er niets van weet. (Bijvoorbeeld zijn voornaam, achternaam, enz.) Er bestaat zoiets als een certificaatverzoek. Meer informatie over deze standaard vindt u bijvoorbeeld op Wikipedia
We gebruiken versie 1.7 - PKCS#10.
Laten we het algoritme beschrijven voor het genereren van een certificaat op Rutoken (originele bron: ):
- We maken een sleutelpaar aan op de client en slaan dit op Rutoken op. (het opslaan gebeurt automatisch)
- We maken een certificaataanvraag aan op de client.
- Vanaf de client sturen wij dit verzoek naar de server.
- Wanneer wij een aanvraag voor een certificaat op de server ontvangen, geven wij een certificaat af van onze certificeringsinstantie.
- Dit certificaat sturen wij naar de opdrachtgever.
- Het Rutoken certificaat bewaren wij op de client.
- Het certificaat moet gebonden zijn aan het sleutelpaar dat in de eerste stap is aangemaakt.
Nu wordt duidelijk hoe de server de handtekening van de klant kan ontsleutelen, aangezien deze zelf het certificaat aan hem heeft uitgegeven.
In het volgende deel gaan we dieper in op hoe u uw certificeringsinstantie kunt instellen op basis van de volwaardige open-source cryptografiebibliotheek openSSL.
Bron: www.habr.com