Hur man undertecknar ett dokument med en elektronisk signatur. Hur man signerar en digital signaturfil korrekt Signera xml med en digital signatur

Jag kan inte komma till en allmän förståelse av mekanismerna för att signera xml-dokument. Jag skulle vara tacksam för din hjälp att reda ut det)

Min situation är så här:

1) det finns en certifieringsmyndighet, vars utfärdade certifikat placeras på servrar i Windows-lagringen... personligt, betrodd, och så vidare... inte poängen.

När användaren loggar in i applikationen signerar användaren en slumpmässigt genererad sträng med det certifikat han själv väljer. På servern är denna signatur verifierad:

CAPICOM.SignedData _signedData = new CAPICOM.SignedData(); _signedData.Verify(signedData, false, CAPICOM_SIGNED_DATA_VERIFY_FLAG.CAPICOM_VERIFY_SIGNATURE_AND_CERTIFICATE); if (_signedData.Content != data) throw new Exception("Signaturinnehållet matchar inte det mottagna innehållet"); var _certificate = _signedData.Certificates; // användarcertifikat

Så här får vi användarcertifikatet (public key). Det viktiga är att signaturen endast verifieras om motsvarande publika nyckel för certifikatet finns på servern i certifikatarkivet. Detta är vad vi behöver, att bara släppa in de vars certifikat vi själva släppt) Det verkar tydligt här.

2) nu behöver vi samma användare att signera xmls med sina certifikat. Min programvara på klienten genererar själva xml:erna och signerar dem med det användarspecificerade certifikatet:

Public static void SignXml(XmlDocument xmlDoc, /*RSA*/AsymmetricAlgorithm Key) ( SignedXml signedXml = new SignedXml(xmlDoc); signedXml.SigningKey = Key; Reference reference = new Reference(); reference.Uri = "";//signature hela xml-dokumentet XmlDsigEnvelopedSignature(referens.AddTransform(env signedXml.Reference KeyInfo(keyInfo.AddClause(CryptService.GetKeyInfoClause(Key) signedXml.KeyInfo; ; XmlElement xmlDigitalSignature = signedXml.GetXml( xmlDoc.DocumentElement.AppendChild(xmlDoc.ImportNode(xmlDigitalSignature, true));

XmlDocument doc = new XmlDocument(); doc.PreserveWhitespace = sant; doc.Load(sökväg); SignedXml sx = new SignedXml(doc); XmlNodeList nodeList = doc.GetElementsByTagName("Signatur"); sx.LoadXml((XmlElement)nodeList); returnera sx.CheckSignature();

Koden fungerar, men jag har frågor med förståelse: i det här fallet kan du signera xml:en med absolut vilket certifikat som helst som inte är utfärdat av vår CA, och eftersom informationen om den publika nyckeln lagras i den signerade xml:en, verifieras signaturen . Det här alternativet passar mig inte. CheckSignature-metoden har en överbelastning med en parameter av typen AsymmetricAlgorithm, som kommer att kontrollera att signeringscertifikatet finns i butiken, kontrollera dess giltighet, utgångsdatum och så vidare. Det här är vad jag behöver, men jag vet inte i förväg vilken användare som skickade den signerade xml.

Snälla berätta för mig: hur man kontrollerar en xml-signatur eller hur man skapar den korrekt så att endast de xml-filer som endast är signerade med våra certifikat (som är installerade i lagringen) verifieras?

P.s. och vad är den allmänna poängen med att behålla både signaturen och den publika nyckeln för att dekryptera signaturen i xml? Om du tar bort raden signedXml.KeyInfo = keyInfo; , då klarar inte xml signaturverifiering.

ML, eller eXtensible Markup Language, håller nu på att bli standardsättet att transportera information på webben (och bortom). Dessutom dyker det upp fler och fler tillägg som använder XML-syntax (XML-applikationer). Till exempel inkluderar dessa det förenklade objektåtkomstprotokollet SOAP (Simple Object Access Protocol), där XML fungerar som ett universellt medel för att representera parametrar för att anropa fjärrprocedurer RPC (Remote Procedure Call). Ett annat exempel på en plugin är ramverket RDF (Resource Description Framework). Du kan ta en titt på World Wide Web Consortium (W3C), som utvecklar standarder inom detta område (http://www.w3.org/), och se att XML verkligen får ökad uppmärksamhet.

Låt oss komma ihåg att huvudsyftet med XML är att beskriva strukturen och semantiken i ett dokument. Den största fördelen med XML jämfört med andra elektroniska dokumentformat är att det skiljer beskrivningen av den externa presentationen av ett dokument från dokumentets struktur och dess innehåll. XML är ett flexibelt språk som kan användas för en mängd olika ändamål och kan samverka med många system och databaser. Således används idag XML i många informationssystem som det huvudsakliga datautbytesformatet. Dessutom har tillverkare av databashanteringssystem tagit ett kraftfullt steg mot XML. Till exempel har Oracle släppt XSU (XML-SQL Utility), som är ett tillägg till JDBC som låter dig lagra och hämta XML-data i en databas (http://otn.oracle.com/tech/xml/ xdk_java/content .html). XSU är en hierarki av Java-klasser utformade för att omvandla data från objektrelationella databastabeller och vyer till XML-format, infoga data från XML-dokument i tabeller och vyer och andra användbara operationer.

Behovet av att skydda XML-dokument

ML är ett kraftfullt verktyg som ofta används för att utbyta data över Internet. Men tyvärr tillhandahåller den inte i sig det nödvändiga skyddet för de data som den "transporterar". Med andra ord, det finns allvarliga säkerhetsproblem när du använder XML-formatet (som, faktiskt, när du använder andra format).

XML kan enkelt användas för att överföra transaktionsmeddelanden mellan en bank och en bankomat, konfidentiell eller halvkonfidentiell information om individer, information om elektroniska transaktioner, eller helt enkelt för att överföra patentskyddade dokument i detta format. Men samtidigt är det nödvändigt att säkerställa skyddet av information från ofrivillig eller avsiktlig förvrängning både från användare av informationssystem och när den överförs via kommunikationskanaler. Skydd bör baseras på följande funktioner:

  • autentisering av interagerande parter;
  • bekräftar informationens äkthet och integritet;
  • kryptografisk stängning av överförda data.

För att säkerställa detta informationsskydd är det tillrådligt att använda elektroniska digitala signaturer (EDS) och datakrypteringsmetoder. Dessutom tillhandahåller digital signatur som regel autentisering, bekräftelse av äkthet och integritet, och datastängning uppnås genom kryptering.

Allmän information om elektroniska digitala signaturer

EDS och möjligheten till dess förfalskning

Elektronisk digital signatur är data som läggs till det ursprungliga informationsblocket (dokumentet), erhållet som ett resultat av dess kryptografiska transformation (beroende på den hemliga nyckeln och det ursprungliga informationsblocket eller dokumentet). EDS säkerställer integriteten hos meddelanden (dokument) med garanterad identifiering av dess författare (personen som undertecknade dokumentet), oftast sänds över oskyddade offentliga telekommunikationskanaler.

Verifiering av den elektroniska digitala signaturen av ett informationsblock utförs genom kryptografisk transformation av den digitala signaturen med användning av den publika nyckeln som motsvarar den hemliga nyckeln som deltog i processen för att installera den digitala signaturen.

Omöjligheten att förfalska en elektronisk digital signatur uppnås genom att använda en mycket stor mängd matematiska beräkningar (till exempel kan omöjligheten att förfalska en signatur bero på komplexiteten i att lösa problemet med diskret logaritm i ett fält av p-element El-Gamal signaturschema). Att placera en signatur på ett dokument ändrar inte själva dokumentet, utan gör det bara möjligt att verifiera äktheten och upphovsrätten till den mottagna informationen (det vill säga ett datablock läggs till i själva dokumentet eller separat från det - den digitala signaturen av det här dokumentet).

Certifieringsmyndighet

Ovan nämnde vi termerna "privat nyckel" och "offentlig nyckel". Var kom dessa nycklar ifrån? De är bildade av en certifieringsmyndighet – en viss struktur (organisation) som hanterar certifikat. Ett offentligt/privat nyckelcertifikat representerar följande uppsättning data:

  • namnet på ett subjekt eller objekt i systemet som unikt identifierar det i systemet;
  • offentlig/privat nyckel för ett ämne eller objekt i systemet;
  • ytterligare attribut som bestäms av kraven för att använda certifikatet i systemet;
  • utgivarens (certifieringsmyndighet) elektroniska digitala signatur som intygar alla dessa data.

Således innehåller till exempel ett privat nyckelcertifikat själva den privata nyckeln och ytterligare information om den.

För varje registrerad användare av informationssystemet genererar certifieringscentret (CA) två certifikat: ett privat nyckelcertifikat och ett offentligt nyckelcertifikat. I det här fallet utfärdas den första SO personligen till den registrerade användaren (till exempel på en diskett) och till ingen annan - detta är "signaturen". Det andra certifikatet, öppet, publiceras av CA i ett offentligt arkiv så att alla som är intresserade enkelt kan hitta det.

Generering och verifiering av digital signatur

Avsändaren av information, med hjälp av en hemlig nyckel och en asymmetrisk algoritm (digital signaturalgoritm) förvald enligt överenskommelse mellan abonnenter, krypterar den överförda informationen, presenterad i digital form, och får således en digital signatur av datan. Därefter skickar avsändaren av informationen den okrypterade informationen och den digitala signaturen som erhållits på det sätt som beskrivits ovan till mottagaren via en öppen kommunikationskanal.

Mottagaren av meddelandet, med hjälp av en publik nyckel (som är allmänt tillgänglig) och en digital signaturalgoritm vald genom överenskommelse mellan abonnenter, avklassificerar den digitala signaturen. Därefter jämför han den okrypterade informationen han fick och informationen som erhölls vid dekryptering av den digitala signaturen. Om den digitala signaturen inte har förfalskats och den överförda öppna informationen inte är förvrängd, bör dessa två informationer helt matcha. Om signaturen är förfalskad kommer den mottagna öppna informationen och informationen som erhålls under dekrypteringen att skilja sig väsentligt (fig. 1).

Hash-funktioner

I ovanstående interaktionsschema mellan avsändaren och mottagaren saknas en operation. Det är associerat med datakrypteringsstadiet, under vilket en elektronisk digital signatur bildas. Om vi ​​bara genererar en digital signatur kommer det att visa sig (beroende på algoritmen), som regel ungefär samma längd som det ursprungliga datablocket, och vi måste skicka ett meddelande med dubbel längd över nätverket. Naturligtvis skulle detta påverka hela driften av systemet negativt. Därför, innan en digital signatur genereras, bearbetas originaldatan med hjälp av en hashfunktion, och signaturen blir därför kompakt. Naturligtvis, för att erhålla det korrekta resultatet, måste mottagaren utföra samma transformation på det mottagna datablocket.

Den använda hashfunktionen måste kunna omvandla ett meddelande av valfri längd till en binär sekvens med en fast längd. Dessutom måste den uppfylla följande krav:

  • meddelandet efter applicering av hash-funktionen måste bero på varje bit av det ursprungliga meddelandet och på deras ordning;
  • Med en hashad version av ett meddelande finns det inget sätt att återställa själva meddelandet.

Förstå kryptering

Datakryptering och dess skillnad från digital signatur

Informationskryptering är en en-till-en matematisk (kryptografisk) transformation, beroende på nyckeln (hemlig transformationsparameter), som matchar ett block av öppen information, presenterad i någon digital kodning, med ett block av krypterad information, även presenterad i digital kodning. Kryptering kombinerar två processer: kryptering och dekryptering av information (Fig. 2).

Den grundläggande skillnaden mellan digital signatur och krypteringsmetoder (vi överväger nu asymmetriska algoritmer, där olika men matematiskt relaterade nycklar används för kryptering och dekryptering) är att vid kryptering används mottagarens publika nyckel och vid dekryptering en privat nyckel , medan i Den digitala signaturalgoritmen kräver författarens hemliga nyckel för att signera ett meddelande, och meddelandeförfattarens publika nyckel för att verifiera den digitala signaturen.

Brytning

Teoretiskt sett kan alla krypteringsalgoritmer som använder en nyckel brytas genom att söka igenom alla nyckelvärden. Om nyckeln väljs ökar den erforderliga datoreffekten exponentiellt med nyckelns längd. En 32-bitars nyckel kräver 232 (cirka 109) steg. Denna uppgift kan utföras av alla amatörer och kan lösas på en hemdator. System med en 40-bitars nyckel (till exempel den exporterade amerikanska versionen av RC4-algoritmen) kräver 240 steg. Sådan datorkraft är tillgänglig i de flesta små företag. System med 56-bitars nycklar (DES) kräver betydande ansträngning för att öppna, men de kan lätt öppnas med hjälp av specialutrustning. Kostnaden för sådan utrustning är betydande, men den är överkomlig för maffian, stora företag och regeringar. Nycklar med en längd på 64 bitar kan för närvarande öppnas av stora stater, och under de närmaste åren kommer de att vara tillgängliga för öppning av kriminella organisationer, stora företag och små stater. 80-bitarsnycklar kan bli sårbara i framtiden. Nycklar med en längd på 128 bitar kommer sannolikt att förbli okrossbara av brute force under överskådlig framtid. Längre nycklar kan också användas.

Nyckellängden är dock inte allt. Många chiffer kan brytas utan att prova alla möjliga kombinationer, utan med en speciell algoritm (till exempel med polynomkomplexitet). I allmänhet är det mycket svårt att komma på ett chiffer som inte kunde öppnas med en annan metod, mer effektiv än brute force.

Observera att ett kryptografiskt system bara är så starkt som dess svagaste länk. Ingen aspekt av systemdesign bör förbises, från val av algoritmer till nyckelanvändnings- och distributionspolicyer.

Elektronisk digital signatur av XML-dokument

De som arbetar med XML har länge förstått vikten av att ha kontroll över data som överförs och representeras i XML. Huvudkraven för de överförda uppgifterna är autentisering av interagerande parter och bekräftelse av äktheten och integriteten för informationen i XML-dokumentet. Sådana problem löses genom digital signatur av XML-dokument.

Specifikationer för digital signatur XML från W3C

W3C utvecklar för närvarande XML Signature Syntax and Processing-specifikationen och andra relaterade dokument. För närvarande har den status som en rekommendation (http://www.w3.org/TR/xmldsig-core/). Detta dokument ger möjlighet att signera både hela XML-dokumentet och en del av det. För att göra XML-signeringsprocessen unik, definieras konceptet med en kanonisk representation av XML-data. Till exempel, i ett XML-dokument, kan taggar som är på samma nivå i hierarkiträdet blandas ihop, vilket skapar otydlighet för signeringsprocessen. Den kanoniska representationen av XML är en sorts sortering (eller snarare, reduktion till den enklaste formen) som inte tillåter sådana friheter. XML-kanoniseringsmetoder och regler beskrivs i ett separat dokument, "Canonical XML" (http://www.w3.org/TR/xml-c14n), som också har status som en rekommendation. Annat material relaterat till XML-dokumentsignering finns på: http://www.w3.org/Signature/.

Märka XML-signatur

Rekommendationen "XML-signatursyntax och bearbetning" anger att signaturen och information om den ska finnas i taggen , som har följande delar (de behövs främst för signaturverifiering):

  • CanonicalizationMethod definierar en specifik uppsättning regler för att förenkla och strukturera XML-instansen innan signering. Denna information säkerställer att den signerade datan är i korrekt form så att verifieringsalgoritmen ger ett positivt resultat om innehållsdata inte har ändrats;
  • signaturmetoden (SignatureMethod) definierar signaturalgoritmen för meddelandesammandragen. Meddelandesammandrag är en unik teckensträng av fast storlek, den är resultatet av databearbetning med en enkelriktad hashfunktion specificerad av sammanfattningsmetoden;
  • digest method (DigestMethod) algoritm för att kompilera en sammanfattning av ett meddelande signerat med en given signaturmetod. Att specificera en specifik sammanfattningsmetod säkerställer att data bearbetas på samma sätt;
  • digest-värde (DigestValue) själva meddelandesammandraget, det vill säga en sträng med fast längd som produceras som ett resultat av databearbetning med hjälp av sammanfattningsalgoritmen. En sådan sträng är unik och oåterkallelig: det är praktiskt taget omöjligt att få den från annat innehåll, och det är inte heller möjligt att återskapa originaldata från den. Det är som ett fingeravtryck för de uppgifter som signeras; en positiv jämförelse av smältvärden garanterar innehållets integritet;
  • signaturen i sig (SignatureValue) detta är data som erhålls efter bearbetning med signaturmetoden;
  • information om den publika nyckeln (KeyInfo) för verifiering av digital signatur. Mer exakt, inte en nyckel, utan ett certifikat, för i det, förutom själva nyckeln, kan ägarens namn och den digitala signaturalgoritmen anges.

Detta är naturligtvis inte uttömmande information om vad som kan finnas i taggen. . Här är det enklaste exemplet på en sådan signatur (lista 1).

Bildande av digital signatur XML

Det bör noteras att det finns vissa skillnader mellan XML-signeringsprocessen och den klassiska. Faktum är att processen att signera en XML-instans börjar med kanonisering, det vill säga med förenkling av datastrukturen. Som redan nämnts är denna procedur nödvändig för att den digitala signaturen ska kunna verifieras korrekt för samma XML-dokument, presenterad på olika sätt. Detta innebär att alla XML-dokument måste konverteras till en enda kanonisk form innan de signeras. Resten av stegen är desamma som standardprocessen för att lägga till en digital signatur: ett sammanfattningsvärde skapas för data med den angivna metoden, sedan signeras detta värde med dokumentförfattarens privata nyckel.

Verifiering av digitala XML-signaturer

För att verifiera en signatur måste du utföra två steg: verifiera själva signaturen och verifiera sammanfattningsvärdet.

Själva signaturen verifieras först för att säkerställa autentisering av dess ägare och förhindra avvisning. Sammanfattningsvärdet kontrolleras sedan för att säkerställa att data inte har ändrats och integriteten för XML-dokumentets innehåll verifieras.

Kryptering av XML-dokument

W3C-specifikationer för XML-kryptering

Låt oss gå vidare till kryptering, vilket gör att vi kan stänga (det vill säga omvandla till en form där innebörden är oklar) den överförda informationen och återställa den på den mottagande sidan. W3C-konsortiet har skapat en arbetsgrupp (http://www.w3.org/Encryption/2001/) som specifikt behandlar frågor om kryptering av XML-data. XML Encryption Syntax and Processing-specifikationen är nu en rekommendation och finns tillgänglig på: http://www.w3.org/TR/xmlenc-core/ .

Märka

  • krypteringsmetod (EncryptionMethod) beskriver datakrypteringsalgoritmen. Om denna tagg saknas måste krypteringsalgoritmen vara känd för den mottagande sidan, annars är dekryptering av meddelandet omöjligt;
  • krypterad data (CipherData) faktisk krypterad data eller en länk till dess plats. Mångfalden av datatyper som ska krypteras och metoderna för deras logiska organisation är praktiskt taget obegränsad;
  • information om nycklar (KeyInfo) information om de nycklar med vilka kryptering och följaktligen dekryptering utförs. De kan lagras någon annanstans och ersättas i XML-instansen med en URL-länk;
  • annan information (till exempel om tilltänkta mottagare).

Tagg exempel visas i lista 2.

Kryptering och dekrypteringsprocess

XML-data krypteras med traditionella kryptografimetoder med offentlig nyckel. Först krypteras själva datan, vanligtvis med hjälp av en slumpmässigt genererad hemlig nyckel, som sedan också krypteras med den avsedda mottagarens publika nyckel. Denna information paketeras så att endast den avsedda mottagaren kan extrahera den hemliga nyckeln och dekryptera data. Den hemliga nyckeln används för att dekryptera den hemliga nyckeln, och sedan dekrypteras data med den hittade hemliga nyckeln.

Implementera XML-dokumentskydd

Vi gick igenom de allmänna principerna för driften av elektroniska digitala signaturer och de specifikationer som W3C-konsortiet har tagit fram inom detta område. Det här är väl och bra, men vad händer om det verkligen finns ett behov av att implementera de beskrivna XML-dataskyddssystemen?

Redan idag, trots att W3C-standarder dök upp ganska nyligen, har vissa företag tillkännagivit lanseringen av sina paket (klassbibliotek) som implementerar både digital signatur och kryptering. Låt oss titta på kapaciteten hos några av dem.

XML Security Suite (IBM)

Det här paketet, baserat på programmeringsspråket Java, finns tillgängligt på http://www.alphaworks.ibm.com/tech/xmlsecuritysuite. XML Security Suite är ett verktyg som tillhandahåller säkerhetsfunktioner som digital signering, kryptering och åtkomstkontroll för XML-dokument. Med dess hjälp kan du uppnå större framgång än att använda funktionerna i transportlagersäkerhetsprotokoll (till exempel Secure Sockets Layer, SSL).

Detta paket implementerar tre teknologier:

  • Den digitala signaturen är baserad på "XML Signature Syntax and Processing"-specifikationen från W3C och IETF (och på "Canonical XML"-specifikationen);
  • kryptering implementeras baserat på "XML Encryption Syntax and Processing"-specifikationen från W3C;
  • åtkomstkontroll för XML-dokument (XML Access Control Language).

XML Security Suite är ett av de bästa moderna verktygen för att skydda XML-dokument. Förutom själva arkivet (JAR) med klassbiblioteket innehåller det detaljerad dokumentation och exempel som gör att du snabbt kan navigera i klasshierarkin.

XML-säkerhet (Apache)

XML-baserat dataskydd

Security Assertion Markup Language (SAML)

Ett område som skiljer sig från att skydda XML-data, men som är nära relaterat till det, är att förbättra säkerheten och säkerheten för XML-baserade system (protokoll). I detta fall skyddas andra dokument/system/applikationer med XML. För närvarande håller säkerhetskommittén för Organisationen för främjande av strukturerade informationsstandarder (OASIS) på att utveckla ett SAML (Security Assertion Markup Language).

Federal lag "om elektronisk digital signatur"

Mål

Låt oss ta en liten paus från lagstiftare inom webbområdet och överväga den federala lagen "om elektronisk digital signatur", som godkändes av Rysslands president den 10 januari 2002 (http://www.internet-law .ru/intlaw/laws/ecp.htm). Antagandet av denna lag gav de rättsliga förutsättningarna för användning av elektroniska digitala signaturer i elektroniska dokument, under förutsättning att en elektronisk digital signatur i ett elektroniskt dokument erkänns som likvärdig med en handskriven signatur i ett pappersdokument. Därmed har grunden lagts för att skapa en juridiskt betydelsefull elektronisk dokumenthantering.

Villkor för likvärdighet mellan digital signatur och vanlig signatur

Lagen definierar de grundläggande begrepp som används i det digitala signaturförfarandet, såsom ett certifikat, offentliga och privata nycklar, bekräftelse av äktheten av en elektronisk digital signatur (vi har granskat dem tidigare), etc. Vidare definierar lagen under vilka förutsättningar en elektronisk digital signatur i ett elektroniskt dokument motsvarar en signatur i ett dokument på papper. Detta betyder, för det första, att signaturnyckelcertifikatet relaterat till denna elektroniska digitala signatur inte har förlorat sin kraft vid tidpunkten för verifiering eller vid tidpunkten för undertecknandet av det elektroniska dokumentet. Dessutom ska äktheten av den elektroniska digitala signaturen bekräftas och att den digitala signaturen används i enlighet med den information som anges i signaturnyckelcertifikatet.

Certifikat och certifieringsmyndigheter

Lagen beskriver i detalj vad ett signaturnyckelcertifikat består av (unikt registreringsnummer, fullständigt namn på ägaren, offentlig digital signaturnyckel, namn och plats för certifieringscentralen etc.); villkor och tillvägagångssätt för att lagra certifikatet i certifieringscentret. Lagringstiden för ett signaturnyckelcertifikat i form av ett elektroniskt dokument i en certifieringscentral bestäms således av en överenskommelse mellan certifieringscentralen och ägaren av signaturnyckelcertifikatet. När det gäller lagring bestäms det av Ryska federationens lagstiftning om arkiv och arkivärenden.

Ett separat kapitel i lagen ägnas åt certifieringscentra. Processen med att utveckla och verifiera en elektronisk digital signatur kan ske utan medverkan av certifieringscenter, om detta bekräftas av en överenskommelse mellan parterna. I offentliga informationssystem och i många företagsinformationssystem är det dock omöjligt att använda digitala signaturer utan att certifieringscentra fungerar, eftersom detta kommer att leda till ganska enkla mekanismer för att förfalska en signatur.

Privata (hemliga) nycklar

En elektronisk digital signatur kan utföra sina funktioner endast om undertecknaren har viss information som är otillgänglig för främlingar. Denna information liknar en krypteringsnyckel och kallas därför "den privata nyckeln till en elektronisk digital signatur" (tidigare användes den liknande termen "hemlig nyckel"). Det är nödvändigt att hålla både den privata nyckeln och krypteringsnyckeln hemliga, eftersom kunskapen om den privata signeringsnyckeln motsvarar ett tomt pappersark med signaturen från ägaren av den privata nyckeln, på vilket en angripare kan skriva vilken text som helst som hänföras till den verkliga ägaren av den privata nyckeln. Konst. 12 i lagen anger direkt skyldigheten för ägaren av signaturnyckelcertifikatet att hålla den privata nyckeln hemlig och att omedelbart kräva indragning av signaturnyckelcertifikatet om det finns anledning att anta att hemligheten för den privata signaturnyckeln har kränkts.

Konst. 5 i lagen fastställer förfarandet för att skapa privata signaturnycklar med hänsyn till strikt iakttagande av sekretessen för deras skapande. Art.nr pekar också på samma omständighet. 9 i lagen om certifieringscentras verksamhet. I företagsinformationsstrukturer kan frågan om att producera och distribuera EDS privata nycklar lösas med sina egna metoder, dock måste EDS-användaren vara medveten om de möjliga konsekvenserna av att en sådan organisation av EDS fungerar. Det är mycket möjligt att någon vanlig sekvens kommer att användas som en privat nyckel, vilket händer när man använder ett lösenordssystem.

Inhemska standarder för digitala signaturalgoritmer

El Gamal-schema

1994 antogs den första inhemska standarden inom området digital signatur GOST R34.10 94 "Informationsteknik. Kryptografiskt informationsskydd. Rutiner för att utveckla och verifiera en elektronisk digital signatur baserad på en asymmetrisk kryptografisk algoritm." Den definierar procedurer för att arbeta med digitala signaturer baserade på ElGamal-schemat. Omöjligheten att förfalska en signatur beror på komplexiteten i att lösa problemet med diskret logaritm i ett fält av p-element eller komplexiteten i att bestämma talet x som ges till ett stort primtal p och talen a, b från intervallet från 2 till p-1, som utförs genom jämförelse:

Ax==bmodp.

Matematiker står dock inte stilla och på senare tid har stora framsteg gjorts i utvecklingen av metoder för att lösa problemet med diskret logaritm i ett fält av p-element. Nyligen skapades den så kallade nummerfältsållmetoden. Med dess hjälp kan du hacka den digitala signaturen som genereras av metoden ovan (åtminstone när det gäller 512-bitarsmodulen p).

En av de enklaste lösningarna på detta problem är att öka längden på modulen p. Men, tyvärr, när p ökar, försämras algoritmens operativa egenskaper, eftersom längden på den publika nyckeln och tiden för att generera och verifiera signaturen ökar.

Elliptisk kurva

Ryska forskare kom så småningom till slutsatsen att det var möjligt att något komplicera El-Gamal-systemet och på så sätt, utan extra beräkningskostnader, öka komplexiteten i digital signaturförfalskning med många tusen gånger. En ny version av ElGamal-schemat använder apparaten för elliptiska kurvor över ett ändligt fält av p-element, som definieras som en uppsättning av par av tal (x, y) (var och en av dem ligger i intervallet från 0 till p-1 ) som uppfyller jämförelsen (siffrorna a och b är fasta och motsvarar något ytterligare villkor):

Y2 == x3 + ax + bmodp.

Andra resurser

  • Information om Oracle XML-SQL Utility http://otn.oracle.com/tech/xml/xdk_java/content.html
  • SAML-specifikationer http://www.oasis-open.org/committees/security/
  • XKMS-specifikation http://www.w3.org/TR/xkms/
  • Federal lag "om elektronisk digital signatur"

Idag, när nästan allt dokumentflöde blir papperslöst, är det vanligt att signera dokument med hjälp.

Inom området offentlig upphandling signeras inlämnade ansökningar elektroniskt. Detta ger kunderna garantin att de har att göra med riktiga deltagare. Dessutom träder avtal som ingås som ett resultat av statlig upphandling i kraft först efter påskrift med hjälp av en elektronisk digital signatur.

En digital signatur krävs också i följande situationer:

  1. Rapportering till tillsynsmyndigheter. Du kan skicka in det elektroniskt till tjänster som Federal Tax Service, Rosstat, Pension Fund och Social Insurance Fund. Detta förenklar överföringen av information avsevärt och ökar noggrannheten: de flesta tjänster erbjuder automatisk felkontroll.
  2. Elektronisk dokumenthantering (EDF). En av de vanligaste användningsområdena, eftersom ett brev undertecknat på detta sätt motsvarar ett pappersbrev med stämpel och visum. Gör att du kan byta till papperslöst dokumentflöde både inom och utanför företaget.
  3. Statliga tjänster. En medborgare i Ryska federationen kan godkänna inlämnade ansökningar till avdelningar via portalen för statliga tjänster, delta i offentliga initiativ, använda ett personligt konto på den federala skattetjänstens webbplats och till och med ansöka om ett lån.
  4. Fakturor, kontrakt, officiella brev undertecknade elektroniskt kan användas som bevis. Enligt Ryska federationens skiljeförfarandekod är ett sådant dokument analogt med ett pappersdokument med ett handskrivet visum.

Vilka typer av elektroniska signaturer finns det?

En elektronisk digital signatur är en "stämpel" som låter dig identifiera dess ägare, samt verifiera integriteten hos det undertecknade dokumentet. Typerna av digitala signaturer och förfarandet för deras utförande har godkänts. Han konstaterade att det finns tre typer av signaturer:

  1. Enkel. Används vanligtvis för att signera brev eller specifikationer, bekräftade med lösenord, koder och andra sätt, oftast används i företagens EDI-system.
  2. Förstärkt. Den erhålls genom processen för kryptografisk behandling av information och användning av en privat nyckel. Låter dig avgöra vem som undertecknat dokumentet, samt det faktum att ändringar gjordes efter undertecknandet.
  3. Förstärkt. Det liknar en okvalificerad, men för att skapa och verifiera den används kryptografiska skyddstekniker certifierade av FSB i Ryska federationen. Sådana elektroniska signaturer utfärdas endast av ackrediterade

Det finns flera sätt att godkänna ett dokument. Låt oss titta på de vanligaste.

Vi signerar med programvaran CryptoPRO CSP

Hur man elektroniskt signerar ett Word-dokument(MS Word)

1. Öppna önskad fil, klicka på menyn "Arkiv" - "Information" - "Lägg till elektronisk signatur (CRYPTO-PRO)".

2. Välj önskad elektronisk signatur, lägg till en kommentar om det behövs och klicka på "Signera".

3. Om det inte finns några fel visar systemet ett fönster med framgångsrik signering.

Om plugin-programmet CryptoPRO Office Signature är installerat

1. Öppna önskad fil, välj "Arkiv" och sedan "Lägg till digital signatur".

2. I likhet med föregående alternativ, välj den elektroniska signaturen, lägg till en kommentar, om det behövs, och klicka på "Signera".

3. Om det inte finns några fel visar systemet ett meddelande om att dokumentet har undertecknats.

Hur man elektroniskt signerar ett PDF-dokument(Adobe Acrobat PDF)

1. Öppna den önskade PDF-filen, klicka på "Verktyg"-panelen och se etiketten "Certifikat". Låt oss välja det.

2. Klicka på "Använd en digital signatur" och välj området på filen där signaturmärket ska finnas.

4. Ett fönster med en förhandsvisning av stämpeln öppnas. Om allt är korrekt klickar du på "Sign".

5. Systemet kommer att utfärda ett meddelande om framgångsrik signering. Det är allt.

Signering med programvaran CryptoARM

Med denna metod är det möjligt att kryptera alla moderna format, såväl som arkiv.

Så låt oss ta reda på det hur man undertecknar ett digitalt signaturdokument använder CryptoARM.

1. Öppna "CryptoARM"-programmet och välj det allra första åtgärdsobjektet - "Sign".

2. Vi studerar noggrant instruktionerna från ES Creation Master. Klicka på "Nästa".

3. Klicka på "Välj fil", gå till önskad fil, klicka på den och klicka på "Nästa".

4. Välj filen som ska signeras och klicka på "Nästa".

5. Vi ser fönstret "Utdataformat". Om det inte finns några obligatoriska krav lämnar vi kodningen som den är. Du kan spara i ZIP-format (för att skicka via e-post) eller välja en plats för att spara det slutliga resultatet. Klicka på "Nästa".

6. I "Parametrar" kan du välja en egenskap, lägga till en kommentar och även välja en bifogad elektronisk signatur (bifogad till källfilen) eller frikopplad (sparad som en separat fil), samt ytterligare parametrar om så önskas. När allt är klart klickar du på "Nästa".

7. Nu måste du välja ett certifikat för att göra detta, klicka på "Välj", ange önskat certifikat och klicka på "Nästa".

8. I nästa steg ser vi det sista fönstret med en kort beskrivning av data. Om nästa gång filerna signeras i samma ordning kan du spara profilen. Klicka på "Slutför".

9. Om det inte finns några fel kommer systemet att visa ett meddelande som indikerar framgångsrik signering.

Ett av de pågående projekten löste problemet med att signera (tillämpa en elektronisk signatur) XML-dokument, nämligen SOAP-paket. Det rekommenderade formatet var OASIS Standard 200401 med X.509 Certificate Token Profile. Dessa dokument beskriver användningen av formatet www-consortium (W3C) XML Digital Signature (XMLDSig) i SOAP-meddelanden. XML-signaturer, liksom andra typer av elektroniska signaturer, stöder autentisering, dataintegritet och icke-avvisande av datasignering.

Jag kommer att notera flera funktioner i XMLDSig-formatet:

1. Inte hela XML-dokumentet kan tjäna som föremål för signering, utan endast en del av det, d.v.s. specifik nod. Enligt OASIS Standard 200401 är objektet som signeras kroppen (nod Kropp) SOAP-meddelanden.

2. Olika delar av ett XML-dokument kan signeras av flera undertecknare.

3. En XML-signatur kan vara på olika nivåer i förhållande till objektet som signeras:

  • signaturstrukturen kan innehålla URI(enhetlig resursidentifierare);
  • XML-signaturen kan vara på samma nivå som noden som signeras;
  • XML-signaturen kan finnas inuti noden som signeras;
  • Noden som signeras kan finnas i en XML-signaturstruktur.

4. För att kontrollera den elektroniska signaturens giltighet krävs tillgång till signeringsobjektet.

Struktur av ett SOAP-kuvert

I allmänhet består ett meddelande av en rubrik och en text: Rubrik Och Kropp. Rubrik innehåller metadata och Kropp data. XML-signaturen placeras i noden Rubrik.

Kryptografiska algoritmer och kanonisering.

För att lösa problemet vi använde GOST R 34,11-94- Rysk kryptografisk standard för hashfunktionsberäkningar och GOST R 34.10-2001- Standard för elektroniska signaturer.

På grund av flexibiliteten i XML-sammansättningsreglerna kan samma dokumentstruktur och samma information representeras av olika XML-dokument. Låt oss titta på två dokument:

Ur en logisk synvinkel är de likvärdiga, det vill säga de har samma XML-schema. Men XML-filerna i dessa listor innehåller inte samma teckensekvens, vilket kommer att leda till olika resultat, till exempel när ett hashvärde hämtas.

För att undvika sådana avvikelser antogs strikta formateringsregler och krav på innehållet i XML-meddelanden. Processen att föra XML-dokument till en enhetlig (kanonisk) form kallas kanonisering(engelska: Canonicalization). Exempel på regler kan vara användning av ett visst kodningsschema (UTF-8), normalisering av attributvärden, användning av dubbla citattecken för attributvärden, en viss ordning på attribut och namnområdesdeklarationer etc. XML-kanonisering finns i flera typer, som skiljer sig åt i reglernas sammansättning. Du kan läsa mer om kanoniseringsprocessen i den officiella W3C-specifikationen (ryskspråkiga artiklar om detta ämne finns och)

SIRCrypt bibliotek

För att implementera XML-signering i DIRECTUM skrevs ett COM-bibliotek, inom vilket 3 klasser beskrivs: Hasher, Undertecknare Och XMLCanonicalizer för att erhålla hash, ES-värde och kanonisering av XML-dokument, respektive.

Biblioteket kräver Crypto PRO CSP(testad på version Crypto PRO CSP 3.6.6497 KC2) Och .NETTO(minst 2,0).

Registrering av ett bibliotek görs genom att köra följande kommando:

> regasm.exe "sökväg till dll" /codebase /tlb

Hasher-objekt för hashberäkning enligt GOST

Innehåller fält Innehåll (skriv "sträng") och HashValueAsBase64 (typ "sträng"), samt en metod för att beräkna hashvärdet Hash(). För att beräkna är det nödvändigt att definiera Innehåll , kalla metoden Hash(), som ett resultat av vilket i fält HashValueAsBase64 hashvärdet kommer att skrivas till Base64.

Signerobjekt för att erhålla ES-värdet enligt GOST

Innehåller fält Innehåll (skriv "sträng"), Behållarnamn (skriv "sträng"), CertificateAsPEM (skriv "sträng"), BESignatureValueAsBase64 (skriv "sträng"), metod Skylt(). Efter initialisering av objektet måste du definiera Innehåll (signeringsdetaljer), Behållarnamn (certifikat för behållare för privat nyckel), anropsmetod Skylt(). Sedan i fält CertificateAsPEM certifikatet som motsvarar den privata nyckeln kommer att finnas i Base64, och fältet BESignatureValueAsBase64 signaturvärde som en Base64-sträng.

XMLCanonicalizer-objekt för XML-kanonisering

Innehåller fält XMLContent (skriv "sträng"), CanonicalXML (skriv "sträng"), metod C14NExc(). För att få det kanoniska XML-formuläret måste du specificera XMLContent , ring upp C14NExc(), få resultatet från fältet CanonicalXML .

XML-signaturstruktur

Att skapa en signatur ser ut så här: först bildas tvålpaketets bas, noderna Rubrik Och Kropp. Kropp fylls med data och ett attribut läggs till wsu:ID="Kropp"- identifierare för de signerade uppgifterna.

Fyller strukturen säkerhet sker i följande ordning:

  1. Hashvärdet från Body-noden tas i kanonisk form och placeras i DigestValue-noden.
  2. Knut Signerad info reducerad till kanonisk form, undertecknad av den elektroniska signaturen. Resultatet i Base64-strängformat går in i noden SignaturVärde.
  3. Den publika nyckeln för certifikatet som användes för att signera placeras i noden BinarySecurityToken i Base64-strängformat.

För att kontrollera ES som genereras på detta sätt måste du göra alla steg i omvänd ordning, nämligen:

  1. få den kanoniska formen av ett element Signerad info.
  2. Använd resultatet från föregående steg och kontrollera om ES-värdet från noden är giltigt SignaturVärde med certifikatets publika nyckel. I detta skede kontrolleras endast korrektheten av den elektroniska signaturen, vilket inte garanterar att uppgifterna är oföränderliga.
  3. Om giltighetskontrollen av den elektroniska signaturen lyckas jämförs hashen från noden DigestValue och hashen från noden med data. Om de är ojämlika har de signerade uppgifterna ändrats och hela den elektroniska signaturen är ogiltig.

Användningsexempel

Utvecklingskit och bibliotek

Exempel på XML-signering på ISBL (skript): dev.zip (5,95 KB)

För permanent användning flyttas koden som utför standardsignering av ett färdigt SOAP-kuvert till en funktion SignSOAP().

Ett certifikat från den aktuella användarens personliga certifikatlager används för signering.

Detta avsnitt erbjuder för att ladda ner programmet XML Converter / XML Designer / XML Reports / Just Sign / XML Contact - Rosreestr.

Exempel på att generera elektroniska versioner av dokument med hjälp av XML Constructor-program och deras tryckta analoger med hjälp av XML-rapportprogram kan laddas ner i avsnittet. Vi föreslår också att du tittar på avsnittet där du hittar olika gratisverktyg, bibliotek och mer.

XML-konverteringsprogram konfigurerad för att konvertera XML-filer/Rosreestr-dokument såsom matrikelextrakt, matrikelplaner för territoriet till andra lättanvända format såsom MIF/MID, DXF, CSV, TXT, HTML.

XML Designer-programär konfigurerad för att skapa elektroniska versioner i XML-format av dokument för matrikelverksamhet såsom gränsplaner, tekniska planer, karta (plan) etc. samt meddelanden om pantsättning av lös egendom och anmälningar i enlighet med FATCA-lagen.

XML-rapportprogram konfigurerad för att konvertera elektroniska dokument för matrikelverksamhet såsom gränsplaner, tekniska planer, karta (plan) till motsvarande tryckta (pappers) motsvarigheter.

Bara signera programmet designad för att skapa och verifiera elektroniska digitala signaturer (EDS).

XML-program Contact-Rosreesträr avsedd för interaktion med Rosreestr webbtjänst, d.v.s. skapa ansökningar om matrikelregistrering av tomter och fastigheter, förfrågningar om matrikelinformation, få resultat på dessa ansökningar och förfrågningar.

Alla program (förutom Just Sign och XML Contact-Rosreestr) har ett demoläge som varar i 30 dagar, vilket gör att du kan använda programmens funktionalitet utan begränsningar. När demoperioden löper ut måste du antingen köpa fullständiga versioner av programmen eller sluta använda dem. Simply Sign-programmet är ett gratisprogram och har inga begränsningar för användningen. Contact-Rosreestr XML-programmet är i betatestning och är för närvarande gratis att använda.

VIKTIG! För att konvertera med programmet XML-konverterare eller XML-konstruktör Stora XML-filer måste laddas ner och installeras av en extern XQuery-frågeprocessor och specificeras i lämpligt fält i programmet innan konvertering. För närvarande stöds två fritt tillgängliga frågeprocessorer: AltovaXML 2010 (utvecklad av www.altova.com) och Saxon-HE 9.5 (utvecklad av www.saxonica.com). Du kan ladda ner dem från tillverkarens webbplats eller från denna webbplats med hjälp av länkarna nedan:

VIKTIG! Innan du börjar arbeta med programmen måste du läsa instruktionerna. Detta är särskilt viktigt för XML Constructor-programmet, eftersom det innan arbetet är nödvändigt att förstå principen för detta programs drift. Instruktionerna finns i samma mapp som programmets körbara fil, det vill säga för XML Constructor i mappen "c:\ProgramFiles\XMLCON\XMLConstructor\XMLConstructor-help.rtf". Du kan anropa instruktionerna genom en genväg från huvudmenyn i Windows-program, det vill säga för XML Designer "Start->Program->XML Designer->XML Designer - Instruktioner". För XML Designer-programmet finns instruktioner också tillgängliga via hjälpmenyn.