Lydutstyr

Hvordan signere xml med en elektronisk signatur. Hvordan signere et dokument med en elektronisk signatur. Hvordan signere et Word-dokument med digital signatur

I dag, når nesten all dokumentflyt blir papirløs, er det vanlig å signere dokumenter med hjelp.

Innenfor offentlige anskaffelser signeres innsendte søknader elektronisk. Dette gir kundene garantien for at de har å gjøre med ekte deltakere. Også kontrakter som inngås som et resultat av offentlige anskaffelser trer i kraft først etter påtegning ved hjelp av en elektronisk digital signatur.

En digital signatur kreves også i følgende situasjoner:

  1. Rapportering til tilsynsmyndigheter. Du kan sende den elektronisk til tjenester som Federal Tax Service, Rosstat, Pension Fund og Social Insurance Fund. Dette forenkler overføringen av informasjon og øker nøyaktigheten: de fleste tjenester tilbyr automatisk feilkontroll.
  2. Elektronisk dokumenthåndtering (EDF). En av de vanligste bruksområdene, siden et brev signert på denne måten tilsvarer et papirbrev med stempel og visum. Lar deg bytte til papirløs dokumentflyt både innen og utenfor selskapet.
  3. Offentlige tjenester. En statsborger i den russiske føderasjonen kan godkjenne innsendte søknader til avdelinger gjennom portalen for offentlige tjenester, delta i offentlige initiativer, bruke personlig konto på Federal Tax Service-nettstedet, til og med søke om et lån.
  4. Fakturaer, kontrakter, offisielle brev signert elektronisk kan brukes som bevis. I henhold til den russiske føderasjonens voldgiftsprosedyrekode er et slikt dokument analogt med et papir med et håndskrevet visum.

Hvilke typer elektroniske signaturer finnes det?

En elektronisk signatur er et "stempel" som lar deg identifisere eieren, samt verifisere integriteten til det signerte dokumentet. Typer av digitale signaturer og prosedyren for utførelse av dem er godkjent. Han slo fast at det er tre typer signaturer:

  1. Enkel. Vanligvis brukt for signering av brev eller spesifikasjoner, bekreftet ved hjelp av passord, koder og andre midler, oftest brukt i bedriftens EDI-systemer.
  2. Forsterket. Den oppnås gjennom prosessen med kryptografisk behandling av informasjon og bruk av en privat nøkkel. Lar deg bestemme hvem som signerte dokumentet, samt det faktum at endringer ble gjort etter signering.
  3. Forsterket. Det ligner på en ukvalifisert, men for opprettelse og verifisering brukes kryptografiske beskyttelsesteknologier sertifisert av FSB i Den russiske føderasjonen. Slike elektroniske signaturer utstedes kun av akkreditert

Det er flere måter å godkjenne et dokument på. La oss se på de vanligste.

Vi signerer med CryptoPRO CSP-programvarepakken

Hvordan signere et Word-dokument elektronisk(MS Word)

1. Åpne ønsket fil, klikk på menyen "Fil" - "Informasjon" - "Legg til elektronisk signatur (CRYPTO-PRO)".

2. Velg ønsket elektronisk signatur, legg til en kommentar om nødvendig, og klikk på "Sign".

3. Hvis det ikke er noen feil, viser systemet et vindu med vellykket signering.

Hvis CryptoPRO Office Signature-plugin er installert

1. Åpne ønsket fil, velg "Fil" og deretter "Legg til digital signatur".

2. I likhet med det forrige alternativet, velg den nødvendige elektroniske signaturen, legg til en kommentar, om nødvendig, og klikk på "Signer".

3. Hvis det ikke er noen feil, viser systemet en melding om at dokumentet ble signert.

Hvordan signere et PDF-dokument elektronisk(Adobe Acrobat PDF)

1. Åpne den nødvendige PDF-filen, klikk på "Verktøy"-panelet og se "Sertifikater"-etiketten. La oss velge det.

2. Klikk på "Bruk en digital signatur" og velg området på filen der signaturmerket skal ligge.

4. Et vindu med en forhåndsvisning av stempelet åpnes. Hvis alt er riktig, klikker du på "Sign".

5. Systemet vil gi en melding om vellykket signering. Det er alt.

Signering med programvarepakken CryptoARM

Med denne metoden er det mulig å kryptere alle moderne formater, samt arkiver.

Så la oss finne ut av det hvordan signere et digitalt signaturdokument bruker CryptoARM.

1. Åpne "CryptoARM"-programmet og velg det aller første handlingselementet - "Sign".

2. Vi studerer nøye instruksjonene til ES Creation Master. Klikk "Neste".

3. Klikk på "Velg fil", gå til ønsket fil, klikk på den og klikk på "Neste".

4. Velg filen du vil signere og klikk på "Neste".

5. Vi ser vinduet "Output Format". Hvis det ikke er noen obligatoriske krav, lar vi kodingen være som den er. Du kan lagre i ZIP-format (for sending via e-post) eller velge et sted for å lagre det endelige resultatet. Klikk "Neste".

6. I "Parametere" kan du velge en egenskap, legge til en kommentar og også velge en vedlagt elektronisk signatur (vedlagt til kildefilen) eller løsrevet (lagret som en separat fil), samt flere alternativer valgfri. Når alt er klart, klikk "Neste".

7. Nå må du velge et sertifikat for å gjøre dette, klikk på "Velg", angi det nødvendige sertifikatet og klikk på "Neste".

8. På neste trinn ser vi det endelige vinduet med kort beskrivelse data. Hvis neste gang filene signeres i samme rekkefølge, kan du lagre profilen. Klikk "Fullfør".

9. Hvis det ikke er noen feil, vil systemet vise en melding som indikerer vellykket signering.

Denne delen tilbyr for nedlasting av programmet XML Converter / XML Designer / XML Reports / Just Sign / XML Contact - Rosreestr.

Eksempler på generering av elektroniske versjoner av dokumenter ved hjelp av XML Constructor-programmer og deres trykte analoger ved hjelp av XML-rapporter programmer kan lastes ned i seksjonen. Vi foreslår også å se på seksjonen der du finner ulike gratisverktøy, biblioteker og mer.

XML-konverteringsprogram konfigurert til å konvertere XML-filer/Rosreestr-dokumenter som matrikkelutdrag, matrikkelplaner for territoriet til andre brukervennlige formater som MIF/MID, DXF, CSV, TXT, HTML.

XML Designer-program er konfigurert til å lage elektroniske versjoner i XML-format av dokumenter for matrikkelvirksomhet som grenseplaner, tekniske planer, kart (plan) etc., samt meldinger om pantsettelse av løsøre og meldinger i henhold til FATCA-loven.

XML-rapporter program konfigurert til å konvertere elektroniske dokumenter for matrikkelaktiviteter som grenseplaner, tekniske planer, kart (planer) til tilsvarende trykte (papir) motstykker.

Bare Sign-program designet for å lage og verifisere elektroniske digitale signaturer (EDS).

XML-program Kontakt-Rosreestr er beregnet for interaksjon med Rosreestr-netttjenesten, dvs. opprette søknader om matrikkelregistrering av tomter og fast eiendom, forespørsler om matrikkelinformasjon, innhente resultater på disse søknadene og forespørsler.

Alle programmer (unntatt Just Sign og XML Contact-Rosreestr) har en demomodus som varer i 30 dager, som lar deg bruke programfunksjonaliteten uten begrensninger. Etter at demoperioden utløper, må du enten kjøpe fullversjoner av programmene eller slutte å bruke dem. Just Sign-programmet er gratis program og har ingen bruksbegrensninger. Contact-Rosreestr XML-programmet er i beta-testing og er for øyeblikket gratis å bruke.

VIKTIG! For å konvertere ved hjelp av programmet XML-konvertering eller XML-konstruktør Store XML-filer må lastes ned og installeres av en ekstern XQuery-spørringsprosessor og spesifiseres i det aktuelle feltet i programmet før konvertering. For øyeblikket støttes to fritt tilgjengelige spørringsprosessorer: AltovaXML 2010 (utviklet av www.altova.com) og Saxon-HE 9.5 (utviklet av www.saxonica.com). Du kan laste dem ned fra produsentens nettsted eller fra denne siden ved å bruke lenkene nedenfor:

VIKTIG! Før du begynner å jobbe med programmene, må du lese instruksjonene. Dette er spesielt viktig for XML Constructor-programmet, siden før arbeid er det nødvendig å forstå prinsippet for drift av dette programmet. Instruksjonene er plassert i samme mappe som programmets kjørbare fil, dvs. for XML-konstruktøren i mappen "c:\ProgramFiles\XMLCON\XMLConstructor\XMLConstructor-help.rtf". Du kan ringe instruksjonene gjennom snarveien fra hovedmenyen Windows-programmer, dvs. for XML-konstruktøren "Start->Programmer->XML-konstruktør->XML-konstruktør - Instruksjoner". For XML Designer-programmet er instruksjoner også tilgjengelige via Hjelp-menyen.

ML, eller eXtensible Markup Language, er nå i ferd med å bli standardmåten for å transportere informasjon på nettet (og videre).

Dessuten dukker det opp flere og flere tillegg som bruker XML-syntaks (XML-applikasjoner). For eksempel inkluderer disse den forenklede objekttilgangsprotokollen SOAP (Simple Object Access Protocol), der XML fungerer som et universelt middel for å representere parametere for å kalle eksterne prosedyrer RPC (Remote Procedure Call). Et annet eksempel på en plugin er RDF-rammeverket (Resource Description Framework). Du kan ta en titt på World Wide Web Consortium (W3C), som utvikler standarder på dette området (http://www.w3.org/), og se at XML faktisk får økt oppmerksomhet. La oss huske at hovedformålet med XML er å beskrive strukturen og semantikken til et dokument. Den største fordelen med XML sammenlignet med andre elektroniske dokumentformater er at det skiller beskrivelsen av den eksterne presentasjonen av et dokument fra strukturen til dokumentet og dets innhold. XML er et fleksibelt språk som kan brukes til en rekke formål og kan grensesnitt med mange systemer og databaser. Dermed brukes XML i dag i mange som hovedformat for datautveksling. Dessuten har produsenter av databasestyringssystemer tatt et kraftig steg mot XML. Oracle har for eksempel gitt ut XSU (XML-SQL Utility), som er et tillegg til JDBC som lar deg lagre og hente XML-data i en database (http://otn.oracle.com/tech/xml/ xdk_java/content .html).

XSU er et hierarki av Java-klasser designet for å transformere data fra objektrelasjonelle databasetabeller og visninger til XML-format, sette inn data fra XML-dokumenter i tabeller og visninger og andre nyttige operasjoner.

Behovet for å beskytte XML-dokumenter

ML er et kraftig verktøy som ofte brukes til å utveksle data over Internett. Men dessverre gir den ikke den nødvendige beskyttelsen for dataene den "transporterer". Med andre ord, det er alvorlige sikkerhetsproblemer når du bruker XML-formatet (som faktisk når du bruker andre formater).

  • XML kan enkelt brukes til å overføre transaksjonsmeldinger mellom en bank og en minibank, konfidensiell eller semi-konfidensiell informasjon om enkeltpersoner, informasjon om elektroniske transaksjoner, eller rett og slett for å overføre proprietære dokumenter i dette formatet. Men samtidig er det nødvendig å sikre beskyttelse av informasjon mot ufrivillig eller tilsiktet forvrengning både fra brukere av informasjonssystemer og ved overføring via kommunikasjonskanaler. Beskyttelse bør være basert på følgende funksjoner:
  • autentisering av samhandlende parter;
  • bekrefte ektheten og integriteten til informasjonen;

kryptografisk lukking av overførte data.

For å sikre denne informasjonsbeskyttelsen, anbefales det å bruke elektronisk digital signatur (EDS) og datakrypteringsmetoder. Dessuten gir digital signatur som regel autentisering, bekreftelse av autentisitet og integritet, og datalukking oppnås ved kryptering.

Generell informasjon om elektroniske digitale signaturer

EDS og muligheten for forfalskning

Verifisering av den elektroniske digitale signaturen til en blokk med informasjon utføres ved kryptografisk transformasjon av den digitale signaturen ved å bruke den offentlige nøkkelen som tilsvarer den hemmelige nøkkelen som deltok i prosessen med å installere den digitale signaturen.

Umuligheten av å forfalske en elektronisk digital signatur oppnås ved å bruke en veldig stor mengde matematiske beregninger (for eksempel kan umuligheten av å forfalske en signatur skyldes kompleksiteten i å løse problemet med diskret logaritme i et felt med p-elementer El-Gamal signaturordning). Å plassere en signatur på et dokument endrer ikke selve dokumentet, men gjør det bare mulig å verifisere ektheten og forfatterskapet til informasjonen som mottas (det vil si at en datablokk legges til selve dokumentet eller separat fra det - den digitale signaturen til dette dokumentet).

Sertifiseringsinstans

Ovenfor nevnte vi begrepene "privat nøkkel" og "offentlig nøkkel". Hvor kom disse nøklene fra? De er dannet av en sertifiseringsmyndighet - en bestemt struktur (organisasjon) som administrerer sertifikater. Et offentlig/privat nøkkelsertifikat representerer følgende sett med data:

  • navnet på et subjekt eller objekt i systemet som unikt identifiserer det i systemet;
  • offentlig/privat nøkkel til et emne eller objekt i systemet;
  • tilleggsattributter bestemt av kravene for bruk av sertifikatet i systemet;
  • elektronisk digital signatur fra utgiveren (sertifiseringsmyndigheten), som bekrefter totalen av disse dataene.

Således inneholder for eksempel et privat nøkkelsertifikat selve den private nøkkelen og tilleggsinformasjon om den.

For hver registrerte bruker av informasjonssystemet genererer sertifiseringssenteret (CA) to sertifikater: et privat nøkkelsertifikat og et offentlig nøkkelsertifikat. I dette tilfellet utstedes den første SO personlig til den registrerte brukeren (for eksempel på en diskett) og til ingen andre - dette er "signaturen".

Det andre sertifikatet, åpent, publiseres av CA i et offentlig depot slik at alle interesserte enkelt kan finne det.

Generering og verifisering av digital signatur

Mottakeren av meldingen, ved å bruke en offentlig nøkkel (som er offentlig tilgjengelig) og en digital signaturalgoritme valgt etter avtale mellom abonnenter, deklassifiserer den digitale signaturen.

Deretter sammenligner han den ukrypterte informasjonen han mottok og informasjonen han fikk ved dekryptering av den digitale signaturen. Hvis den digitale signaturen ikke er forfalsket og den overførte åpne informasjonen ikke er forvrengt, bør disse to informasjonene samsvare fullstendig. Hvis signaturen er forfalsket, vil den mottatte åpne informasjonen og informasjonen innhentet under dekryptering avvike betydelig (fig. 1).

Hash-funksjoner

I ovennevnte skjema for samhandling mellom avsender og mottaker mangler én operasjon. Det er assosiert med stadiet av datakryptering, der en elektronisk digital signatur dannes.

  • Hvis vi bare genererer en digital signatur, vil det vise seg (avhengig av algoritmen), som regel omtrent samme lengde som den opprinnelige datablokken, og vi må sende en melding med dobbel lengde over nettverket. Dette vil naturligvis påvirke hele driften av systemet negativt. Derfor, før generering av en digital signatur, behandles originaldataene ved hjelp av en hash-funksjon, og dermed blir signaturen kompakt. Selvfølgelig, for å oppnå riktig resultat, må mottakeren utføre den samme transformasjonen på den mottatte datablokken.
  • Hash-funksjonen som brukes må kunne konvertere en melding av hvilken som helst lengde til en binær sekvens med fast lengde. I tillegg må den oppfylle følgende krav:

meldingen etter bruk av hash-funksjonen må avhenge av hver bit av den opprinnelige meldingen og rekkefølgen deres;

Ved å bruke en hashed versjon av en melding, er det ingen måte å rekonstruere selve meldingen.

Forstå kryptering Datakryptering og dens forskjell fra digital signatur Informasjonskryptering en-til-en matematisk (kryptografisk) transformasjon, avhengig av nøkkelen (hemmelig transformasjonsparameter), som samsvarer med blokken

Den grunnleggende forskjellen mellom digital signatur og krypteringsmetoder (vi vurderer nå asymmetriske algoritmer, der forskjellige, men matematisk relaterte nøkler brukes til kryptering og dekryptering) er at ved kryptering brukes mottakerens offentlige nøkkel, og ved dekryptering, en privat nøkkel , mens i Den digitale signaturalgoritmen krever forfatterens hemmelige nøkkel for å signere en bestemt melding, og for EDS-sjekker offentlig nøkkel til meldingens forfatter.

Hacking

Teoretisk sett kan enhver krypteringsalgoritme som bruker en nøkkel brytes ved å søke gjennom alle nøkkelverdiene. Hvis nøkkelen velges, øker den nødvendige datamaskinkraften eksponentielt med lengden på nøkkelen. En 32-bits nøkkel krever 232 (ca. 109) trinn. Denne oppgaven kan gjøres av enhver amatør og kan løses på en hjemmedatamaskin. Systemer med en 40-bits nøkkel (for eksempel den eksporterte amerikanske versjonen av RC4-algoritmen) krever 240 trinn slik datakraft er tilgjengelig i de fleste små selskaper. Systemer med 56-bits nøkler (DES) krever betydelig innsats for å åpne, men de kan enkelt åpnes ved hjelp av spesialutstyr. Kostnaden for slikt utstyr er betydelig, men det er rimelig for mafiaen, store selskaper og myndigheter. Nøkler med en lengde på 64 biter kan i dag åpnes av store stater, og i løpet av de neste årene vil de være tilgjengelige for åpning av kriminelle organisasjoner, store selskaper og små stater. 80-biters nøkler kan bli sårbare i fremtiden.

Nøkler med en lengde på 128 biter vil sannsynligvis forbli ubrytelige med brute force i overskuelig fremtid. Lengre taster kan også brukes.

Nøkkellengden er imidlertid ikke alt. Mange chiffer kan brytes uten å prøve alle mulige kombinasjoner, men ved å bruke en spesiell algoritme (for eksempel med polynomkompleksitet). Generelt er det veldig vanskelig å komme opp med et chiffer som ikke kunne åpnes ved hjelp av en annen metode, mer effektiv enn brute force.

Merk at et kryptografisk system bare er så sterkt som dets svakeste ledd. Ingen aspekter ved systemdesign bør overses, fra algoritmevalg til nøkkelbruks- og distribusjonspolicyer.

De som jobber med XML har lenge forstått viktigheten av å ha kontroll over dataene som overføres og representeres i XML. Hovedkravene til de overførte dataene er autentisering av samhandlende parter og bekreftelse av autentisiteten og integriteten til informasjonen i XML-dokumentet. Slike problemer løses ved digital signatur av XML-dokumenter.

Spesifikasjoner for digital signatur XML fra W3C

W3C utvikler for tiden XML Signature Syntax and Processing-spesifikasjonen og andre relaterte dokumenter. Foreløpig har den status som en anbefaling (http://www.w3.org/TR/xmldsig-core/).

Dette dokumentet sørger for signering av både hele XML-dokumentet og deler av det. For å gjøre XML-signeringsprosessen unik, er konseptet med en kanonisk representasjon av XML-data definert. For eksempel, i et XML-dokument, kan tagger som er på samme nivå i hierarkietreet blandes sammen, og dermed skape tvetydighet for signeringsprosessen. Den kanoniske representasjonen av XML er en slags sortering (eller rettere sagt, reduksjon til den enkleste formen) som ikke tillater slike friheter. XML-kanoniseringsmetoder og regler er beskrevet i et eget dokument, "Canonical XML" (http://www.w3.org/TR/xml-c14n), som også har status som en anbefaling. Annet materiale relatert til XML-dokumentsignering er tilgjengelig på: http://www.w3.org/Signature/.

Tag XML-signatur

  • "XML-signatursyntaks og -behandling"-anbefalingen spesifiserer at signaturen og informasjon om den skal være inneholdt i taggen
  • , som har følgende deler (de er hovedsakelig nødvendige for signaturverifisering):
  • CanonicalizationMethod definerer et spesifikt sett med regler for å forenkle og strukturere XML-forekomsten før signering. Denne informasjonen sikrer at de signerte dataene er i riktig form slik at verifikasjonsalgoritmen gir et positivt resultat dersom innholdsdataene ikke er endret;
  • digest-verdi (DigestValue) selve meldingssammendraget, det vil si en streng med fast lengde produsert som et resultat av databehandling ved hjelp av sammendragsalgoritmen. En slik streng er unik og irreversibel: det er praktisk talt umulig å få den fra annet innhold, akkurat som det er umulig å gjenskape de originale dataene fra den. Det er som et fingeravtrykk for dataene som signeres;
  • en positiv sammenligning av fordøyelsesverdier garanterer integriteten til innholdet;
  • selve signaturen (SignatureValue) dette er dataene innhentet etter behandling med signaturmetoden;

informasjon om den offentlige nøkkelen (KeyInfo) for verifisering av digital signatur. Mer presist, ikke en nøkkel, men et sertifikat, fordi i den, i tillegg til selve nøkkelen, kan navnet på eieren og den digitale signaturalgoritmen angis. Dette er naturligvis ikke uttømmende informasjon om hva som kan være inneholdt i taggen. . Her enkleste eksempelet

en slik signatur (oppføring 1).

Dannelse av digital signatur XML

Det skal bemerkes at det er noen forskjeller mellom XML-signeringsprosessen og den klassiske.

Faktum er at prosessen med å signere en XML-instans begynner med kanonisering, det vil si med forenkling av datastrukturen. Som allerede nevnt er denne prosedyren nødvendig for at den digitale signaturen skal kunne verifiseres korrekt for det samme XML-dokumentet, presentert på forskjellige måter. Dette betyr at alle XML-dokumenter må konverteres til en enkelt kanonisk form før signering. Resten av trinnene er de samme som standardprosessen for å legge til en digital signatur: en sammendragsverdi opprettes for dataene ved hjelp av den angitte metoden, deretter signeres denne verdien med den private nøkkelen til dokumentforfatteren.

Verifisering av digital signatur i XML

For å bekrefte en signatur, må du utføre to trinn: verifisere selve signaturen og verifisere sammendragsverdien.

Selve signaturen blir først verifisert for å sikre autentisering av eieren og forhindre avvisning. Sammendragsverdien blir deretter kontrollert for å sikre at dataene ikke er endret og integriteten til XML-dokumentinnholdet er verifisert.

La oss gå videre til kryptering, som lar oss lukke (det vil si transformere til en form der meningen er uklar) de overførte dataene og gjenopprette dem på mottakersiden. W3C-konsortiet har opprettet en arbeidsgruppe (http://www.w3.org/Encryption/2001/) som spesifikt tar for seg problemer med kryptering av XML-data. XML Encryption Syntax and Processing-spesifikasjonen er nå en anbefaling og er tilgjengelig på: http://www.w3.org/TR/xmlenc-core/ .

Dette dokumentet sørger for signering av både hele XML-dokumentet og deler av det.

  • krypteringsmetode (EncryptionMethod) beskriver datakrypteringsalgoritmen.
  • Hvis denne taggen mangler, må krypteringsalgoritmen være kjent for mottakersiden, ellers er dekryptering av meldingen umulig;
  • krypterte data (CipherData) de faktiske krypterte dataene eller en kobling til plasseringen. Variasjonen av datatyper som skal krypteres og metodene for deres logiske organisering er praktisk talt ubegrenset;
  • informasjon om nøkler (KeyInfo) informasjon om nøklene som kryptering og følgelig dekryptering utføres med. De kan lagres andre steder og erstattes i XML-forekomsten med en URL-kobling;

annen informasjon (for eksempel om tiltenkte mottakere). Tag eksempel

vist i oppføring 2.

Kryptering og dekrypteringsprosess Kryptering XML-data

produsert ved bruk av tradisjonelle offentlige nøkkelkrypteringsmetoder. Først blir selve dataene kryptert, vanligvis ved hjelp av en tilfeldig generert hemmelig nøkkel, som da også krypteres med den offentlige nøkkelen til den tiltenkte mottakeren. Denne informasjonen er pakket slik at bare den tiltenkte mottakeren kan trekke ut den hemmelige nøkkelen og dekryptere dataene. Den hemmelige nøkkelen brukes til å dekryptere den hemmelige nøkkelen, og deretter dekrypteres dataene ved å bruke den funnet hemmelige nøkkelen.

Implementering av XML-dokumentbeskyttelse

Vi gjennomgikk de generelle prinsippene for drift av elektroniske digitale signaturer og spesifikasjonene som W3C-konsortiet har utviklet på dette området. Dette er vel og bra, men hva om det virkelig er behov for å implementere de beskrevne XML-databeskyttelsesordningene?

Allerede i dag, til tross for at W3C-standarder dukket opp ganske nylig, har noen selskaper annonsert utgivelsen av pakkene deres (klassebiblioteker) som implementerer både digital signatur og kryptering. La oss se på egenskapene til noen av dem.

Denne pakken, basert på programmeringsspråket Java, er tilgjengelig på http://www.alphaworks.ibm.com/tech/xmlsecuritysuite.

XML Security Suite er et verktøy som gir sikkerhetsfunksjoner som digital signering, kryptering og tilgangskontroll for XML-dokumenter. Med dens hjelp kan du oppnå større suksess enn å bruke egenskapene til sikkerhetsprotokoller for transportlag (for eksempel Secure Sockets Layer, SSL).

  • Denne pakken implementerer tre teknologier:
  • Den digitale signaturen er basert på "XML Signature Syntax and Processing"-spesifikasjonen fra W3C og IETF (og på "Canonical XML"-spesifikasjonen);
  • kryptering er implementert basert på "XML Encryption Syntax and Processing"-spesifikasjonen fra W3C;

tilgangskontroll for XML-dokumenter (XML Access Control Language).

XML Security Suite er et av de beste moderne verktøyene for å beskytte XML-dokumenter.

I tillegg til selve arkivet (JAR) med klassebiblioteket, inkluderer det detaljert dokumentasjon og eksempler som lar deg raskt navigere i klassehierarkiet.

XML-sikkerhet (Apache)

XML-basert databeskyttelse

Security Assertion Markup Language (SAML)

En retning som er forskjellig fra å beskytte XML-data, men nært knyttet til det, er å forbedre sikkerheten og sikkerheten til XML-baserte systemer (protokoller). I dette tilfellet er andre dokumenter/systemer/applikasjoner beskyttet med XML. For tiden utvikler sikkerhetskomiteen til Organisasjonen for fremme av strukturerte informasjonsstandarder (OASIS) et Security Assertion Markup Language (SAML).

Føderal lov "om elektronisk digital signatur"

Mål

Loven definerer de grunnleggende begrepene som brukes i prosedyren for digital signatur, som et sertifikat, offentlige og private nøkler, bekreftelse av ektheten til en elektronisk digital signatur (vi har undersøkt dem tidligere), osv. Videre definerer loven vilkårene for hvordan en elektronisk digital signatur i et elektronisk dokument tilsvarer en signatur i et dokument på papir. Dette betyr for det første at signaturnøkkelsertifikatet knyttet til denne elektroniske digitale signaturen ikke har mistet kraft ved verifiseringstidspunktet eller ved signering av det elektroniske dokumentet. I tillegg må ektheten til den elektroniske digitale signaturen bekreftes og at den digitale signaturen brukes i samsvar med opplysningene som er spesifisert i signaturnøkkelsertifikatet.

Sertifikater og sertifiseringsmyndigheter

Loven beskriver i detalj hva et signaturnøkkelsertifikat består av (unikt registreringsnummer, fullt navn på eier, offentlig digital signaturnøkkel, navn og plassering av sertifiseringssenteret, etc.); vilkår og prosedyre for oppbevaring av sertifikatet i sertifiseringssenteret. Lagringsperioden for et signaturnøkkelsertifikat i form av et elektronisk dokument i et sertifiseringssenter bestemmes således av en avtale mellom sertifiseringssenteret og eieren av signaturnøkkelsertifikatet. Når det gjelder lagring, bestemmes det av lovgivningen til Den russiske føderasjonen om arkiver og arkivsaker.

Et eget kapittel i loven er viet sertifiseringssentre. Prosessen med å utvikle og verifisere en elektronisk digital signatur kan foregå uten medvirkning fra sertifiseringssentre, dersom dette bekreftes av en avtale mellom partene. Men i offentlige informasjonssystemer og i mange bedriftsinformasjonssystemer er bruk av digitale signaturer uten at sertifiseringssentre fungerer umulig, siden dette vil føre til ganske enkle mekanismer for å forfalske en signatur.

Private (hemmelige) nøkler

En elektronisk digital signatur kan bare utføre sine funksjoner dersom underskriveren har noe informasjon som er utilgjengelig for fremmede. Denne informasjonen ligner på en krypteringsnøkkel og kalles derfor "den private nøkkelen til en elektronisk digital signatur" (tidligere ble det lignende uttrykket "hemmelig nøkkel" brukt). Det er nødvendig å holde både den private nøkkelen og krypteringsnøkkelen hemmelig, siden kunnskap om den private signeringsnøkkelen tilsvarer et blankt ark med signaturen til eieren av den private nøkkelen, som en angriper kan skrive hvilken som helst tekst på tilskrives den reelle eieren av den private nøkkelen. Kunst. 12 i loven angir direkte plikten for eieren av signaturnøkkelsertifikatet til å holde den private nøkkelen hemmelig og umiddelbart kreve suspensjon av signaturnøkkelsertifikatet dersom det er grunn til å tro at hemmeligheten til den private signaturnøkkelen er krenket.

Kunst. 5 i loven fastsetter prosedyren for å opprette private signaturnøkler under hensyntagen til streng overholdelse av hemmeligheten rundt opprettelsen. Art. peker også på samme forhold. 9 i lov om virksomheten til sertifiseringssentre. I bedriftsinformasjonsstrukturer kan problemet med å produsere og distribuere EDS private nøkler løses ved hjelp av sine egne metoder, men EDS-brukeren må være klar over de mulige konsekvensene av en slik organisering av EDS-fungering. Det er godt mulig at en vanlig sekvens vil bli brukt som en privat nøkkel, slik det skjer når du bruker et passordsystem.

Innenlandske standarder for digitale signaturalgoritmer

El Gamal-ordningen

I 1994 ble den første innenlandske standarden innen digital signatur tatt i bruk GOST R34.10 94 "Informasjonsteknologi. Kryptografisk informasjonsbeskyttelse. Prosedyrer for å utvikle og verifisere en elektronisk digital signatur basert på en asymmetrisk kryptografisk algoritme." Den definerer prosedyrer for arbeid med digitale signaturer basert på ElGamal-ordningen.

Umuligheten av å forfalske en signatur skyldes kompleksiteten ved å løse problemet med diskret logaritme i et felt med p-elementer eller kompleksiteten ved å bestemme tallet x gitt til et stort primtall p og tallene a, b fra intervallet fra 2 til p-1, som er utført ved sammenligning:

Matematikere står imidlertid ikke stille, og i det siste er det gjort store fremskritt i utviklingen av metoder for å løse problemet med diskret logaritme i et felt med p-elementer.

Nylig ble den såkalte tallfeltsilmetoden opprettet. Med dens hjelp kan du hacke den digitale signaturen generert av metoden ovenfor (i det minste når det gjelder 512-bits modulen p). En av de enkleste løsningene på dette problemet er å øke lengden på modulen p. Men, dessverre, etter hvert som p øker, forringes driftsytelsen. egenskapene til algoritmen

, siden lengden på den offentlige nøkkelen og tiden for generering og verifisering av signaturen øker.

Elliptisk kurve

Russiske forskere kom til slutt til den konklusjonen at det var mulig å komplisere El-Gamal-ordningen litt og dermed, uten ekstra beregningskostnader, øke kompleksiteten til digital signaturforfalskning med mange tusen ganger. En ny versjon av ElGamal-skjemaet bruker apparatet med elliptiske kurver over et begrenset felt av p-elementer, som er definert som et sett med tallpar (x, y) (hver av dem ligger i området fra 0 til p-1 ) som tilfredsstiller sammenligningen (tall a og b er faste og tilsvarer en tilleggsbetingelse):

Y2 == x3 + ax + bmodp.

  • Andre ressurser
  • Informasjon om Oracle XML-SQL Utility http://otn.oracle.com/tech/xml/xdk_java/content.html
  • SAML-spesifikasjoner http://www.oasis-open.org/committees/security/
  • XKMS-spesifikasjon http://www.w3.org/TR/xkms/

Føderal lov "om elektronisk digital signatur" Et av de pågående prosjektene løste problemet med å signere (bruke en elektronisk signatur) XML-dokumenter, nemlig SOAP-pakker. Det anbefalte formatet var OASIS Standard 200401 med X.509 Certificate Token Profile. Disse dokumentene beskriver bruken av www-consortium (W3C) formatet for elektronisk XML-signaturer

(XMLDSig - XML ​​​​Digital Signature) i SOAP-meldinger. XML-signaturer, som andre typer elektroniske signaturer, støtter autentisering, dataintegritet og ikke-forkastelse av datasignering.

Jeg vil legge merke til flere funksjoner i XMLDSig-formatet: 1. Ikke hele XML-dokumentet kan tjene som gjenstand for signering, men bare en del av det, dvs. spesifikk node. I henhold til OASIS Standard 200401 er objektet som signeres kroppen (node Kropp

) SOAP-meldinger.

2. Ulike deler av et XML-dokument kan signeres av flere underskrivere.

  • 3. En XML-signatur kan lokaliseres på ulike nivåer i forhold til objektet som signeres: signaturstrukturen kan inneholde URI
  • XML-signaturen kan være på samme nivå som noden som signeres;
  • XML-signaturen kan være inne i noden som signeres;
  • Noden som signeres kan være inneholdt i en XML-signaturstruktur.

4. For å kontrollere gyldigheten av den elektroniske signaturen kreves tilgang til signeringsobjektet.

Strukturen til en SOAP-konvolutt

Generelt består en melding av en overskrift og en brødtekst: Overskrift Og 1. Ikke hele XML-dokumentet kan tjene som gjenstand for signering, men bare en del av det, dvs. spesifikk node. I henhold til OASIS Standard 200401 er objektet som signeres kroppen (node. Overskrift inneholder metadata og 1. Ikke hele XML-dokumentet kan tjene som gjenstand for signering, men bare en del av det, dvs. spesifikk node. I henhold til OASIS Standard 200401 er objektet som signeres kroppen (node data. XML-signaturen plasseres i noden Overskrift.

Kryptografiske algoritmer og kanonisering.

For å løse problemet vi brukte GOST R 34,11-94- Russisk kryptografisk standard for hashfunksjonsberegninger og GOST R 34.10-2001- standard for elektronisk signatur.

På grunn av fleksibiliteten til XML-sammensetningsregler, kan samme dokumentstruktur og samme informasjon representeres av forskjellige XML-dokumenter. La oss se på to dokumenter:

Fra et logisk synspunkt er de likeverdige, det vil si at de har samme XML-skjema. Men XML-filene til disse oppføringene inneholder ikke den samme sekvensen av tegn, noe som vil føre til forskjellige resultater, for eksempel når du henter en hash-verdi.

For å unngå slike avvik ble det vedtatt strenge formateringsregler og krav til innholdet i XML-meldinger. Prosessen med å bringe XML-dokumenter til en enhetlig (kanonisk) form kalles kanonisering(engelsk: Canonicalization). Eksempler på regler kan være bruk av et bestemt kodingsskjema (UTF-8), normalisering av attributtverdier, bruk av doble anførselstegn for attributtverdier, en viss rekkefølge av attributter og navneromserklæringer osv. XML-kanonisering finnes i flere typer, som er forskjellige i sammensetningen av reglene. Du kan lese mer om kanoniseringsprosessen i den offisielle W3C-spesifikasjonen (russiskspråklige artikler om dette emnet kan finnes og)

SIRCrypt bibliotek

For å implementere XML-signering i DIRECTUM ble det skrevet et COM-bibliotek, der 3 klasser er beskrevet: Hasher, Underskriver Og XMLCanonicalizer for å få henholdsvis hash, ES-verdi og kanonisering av XML-dokumenter.

Biblioteket krever Crypto PRO CSP(testet på versjon Crypto PRO CSP 3.6.6497 KC2) Og .NETT(minimum 2,0).

Registrering av et bibliotek gjøres ved å kjøre følgende kommando:

> regasm.exe "bane til dll" /codebase /tlb

Hasher-objekt for hash-beregning i henhold til GOST

Inneholder felt Innhold (skriv "streng") og HashValueAsBase64 (skriv "streng"), samt en metode for å beregne hash-verdien Hash(). For å beregne er det nødvendig å definere Innhold , kall metoden Hash(), som et resultat av dette i feltet HashValueAsBase64 hash-verdien vil bli skrevet til Base64.

Signerobjekt for å oppnå ES-verdien i henhold til GOST

Inneholder felt Innhold (skriv "streng"), Beholdernavn (skriv "streng"), SertifikatAsPEM (skriv "streng"), BESignatureValueAsBase64 (skriv "streng"), metode Skilt(). Etter initialisering av objektet, må du definere Innhold (signeringsdetaljer), Beholdernavn (beholdernavn for sertifikat for privat nøkkel), anropsmetode Skilt(). Så i felten SertifikatAsPEM sertifikatet som tilsvarer den private nøkkelen vil være i Base64, og feltet BESignatureValueAsBase64 signaturverdi som en Base64-streng.

XMLCanonicalizer-objekt for XML-kanonisering

Inneholder felt XMLContent (skriv "streng"), CanonicalXML (skriv "streng"), metode C14NExc(). For å få det kanoniske XML-skjemaet må du spesifisere XMLContent , ring C14NExc(), få resultatet fra feltet CanonicalXML .

XML-signaturstruktur

Å lage en signatur ser slik ut: først dannes bunnen av såpepakken, nodene Overskrift Og 1. Ikke hele XML-dokumentet kan tjene som gjenstand for signering, men bare en del av det, dvs. spesifikk node. I henhold til OASIS Standard 200401 er objektet som signeres kroppen (node. 1. Ikke hele XML-dokumentet kan tjene som gjenstand for signering, men bare en del av det, dvs. spesifikk node. I henhold til OASIS Standard 200401 er objektet som signeres kroppen (node fylles med data og et attributt legges til wsu:ID="Body"- identifikator for signerte data.

Fylling av strukturen Sikkerhet skjer i følgende rekkefølge:

  1. Hash-verdien fra Body-noden tas i kanonisk form og plasseres i DigestValue-noden.
  2. Knute SignertInfo redusert til kanonisk form, signert med den elektroniske signaturen. Resultatet i Base64-strengformat går inn i noden Signaturverdi.
  3. Den offentlige nøkkelen til sertifikatet som ble brukt til å signere, plasseres i noden BinarySecurityToken i Base64-strengformat.

For å sjekke ES generert på denne måten, må du gjøre alle trinnene i omvendt rekkefølge, nemlig:

  1. få den kanoniske formen til et element SignertInfo.
  2. Ved å bruke resultatet fra forrige trinn, kontroller om ES-verdien fra noden er gyldig Signaturverdi ved å bruke sertifikatets offentlige nøkkel. På dette stadiet kontrolleres bare riktigheten av den elektroniske signaturen, noe som ikke garanterer uforanderligheten til dataene.
  3. Hvis gyldighetskontrollen av den elektroniske signaturen er vellykket, sammenlignes hashen fra noden DigestValue og hashen fra noden med dataene. Hvis de er ulikt, er de signerte dataene endret og hele den elektroniske signaturen er ugyldig.

Eksempel på bruk

Utviklingssett og bibliotek

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

For permanent bruk flyttes koden som utfører standardsignering av en ferdig SOAP-konvolutt til en funksjon SignSOAP().

Et sertifikat fra gjeldende brukers personlige sertifikatlager brukes til signering.

I henhold til lov 218-FZ "On State Registration of Real Estate", må elektroniske XML-dokumenter og skannede bilder av dokumenter signeres forbedret kvalifisert elektronisk signatur. Alle programmene i "Polygon"-serien, "Polygon Pro" og "Signature Pro"-programmet er signert med nettopp en slik signatur.

For å signere:

    Bli signaturnøkkel(sertifikat) ved sertifiseringssenteret. Listen over akkrediterte sertifiseringssentre er publisert på nettstedet til Rosreestr (List of Certification Centers). Du kan få et sertifikat på vårt sertifiseringssenter, Software Center LLC.

    Sammen med signaturen, kjøp og installer programmet på datamaskinen din CryptoPro CSP (den inneholder de nødvendige russiske signaturstandardene), som også kan kjøpes fra vårt Certification Center LLC "Program Center".

Andre signaturprogrammer er ikke påkrevd: CryptoARM (CryptoARMs signaturfunksjoner ligner på "Polygon", "Polygon Pro"-serieprogrammene og "Signature Pro"-programmet).

Programvaremoduler til Polygon Pro-plattformen

Signer et elektronisk dokument i Polygon Pro-programmet

Gjør følgende for å signere en XML-fil:

  • Generer et elektronisk dokument uten feil.


Du kan signere XML-filen umiddelbart i " XML Viewer", for å gjøre dette, klikk på knappen på verktøylinjen - "Signer XML-fil".

  • Etter å ha klikket, åpnes et vindu med en liste over installerte sertifikater. Velg den du vil ha og klikk "OK".

  • Programmet signerer hoveddokumentet og viser en suksessmelding.

En signaturfil med samme navn og filtype * vil bli generert i samme mappe som den signerte filen. .sig.

Signer en gruppe filer i Polygon Pro-programmet

Programmet har muligheten til å signere en gruppe filer samtidig. For å gjøre dette, gjør følgende:

  • På båndet til programvaremodulen på fanen "Hjem" trykk på knappen og velg fra undermenyen. Et vindu åpnes med et utvalg prosjektfiler (som standard er alle prosjektfiler valgt).
  • Hvis listen inneholder filer som ikke trenger å signeres, fjerner du merket for dem.

  • Klikk på knappen "Abonner". Et vindu åpnes med en liste over installerte sertifikater. Velg den du vil ha og klikk "OK".
  • Programmet vil signere alle dokumenter og vise en suksessmelding.

    Hvis det oppstår feil under signering, vil det vises en bekreftelseslogg med advarsler og/eller feil. For korrekt signering må feil rettes.

    Signer filen i programvaremodulene til Polygon Pro-plattformen

    Programmet har muligheten til å signere absolutt hvilken som helst fil.

      Et vindu åpnes med en liste over installerte sertifikater. Velg den du vil ha og klikk " OK».

    • Programmet signerer dokumentene og viser en suksessmelding.

    I samme mappe som den signerte filen vil en signaturfil genereres med samme navn, med filtypen *.sig.

    Sjekk den elektroniske signaturen i Polygon Pro-programmet

    Hvis du har mottatt en signert fil fra utsiden og ønsker å sjekke om den er endret, eller bare sjekke at filsignaturen er riktig generert, følger du disse trinnene:

    • På båndet til programvaremodulen i fanen " Hjem"i undermenyen til knappen" Signer alle» klikk på knappen « Sjekke…».

    • Velg filen som inneholder signaturen (med filtypen *.sig), som må verifiseres, eller en signert fil.

    Hvis disse to filene er i forskjellige mapper, vil programmet vise et advarselsvindu. Klikk på knappen Gjenta" og velg kildefilen.

    • Det åpnes en protokoll med informasjon om hvorvidt dokumentet ble signert riktig, av hvem og når.

    Program "Signatur Pro"

    For praktisk interaksjon med sertifiseringsinstansen, administrasjon av digitale sertifikater og private nøkler Elektronisk signatur, samt et program ble utviklet for å signere ulike filer med elektronisk signatur.

    Hvordan signere en fil med en elektronisk digital signatur?

    Denne instruksen er omtrentlig, kan spesifikke trinn avhenge av hva som er installert på datamaskinen programvare. En del av instruksjonene ble fullført i februar 2012, men programmene våre gir et mer praktisk alternativ for å signere elektroniske dokumentfiler forbedret kvalifisert elektronisk signatur.

    Slik signerer du elektroniske dokumentfiler: grenseplan, kartplan, teknisk plan elektronisk signatur må verifiseres installerte programmer:

      kryptoleverandør "CryptoPro CSP";

      "Crypto ARM" - dette programmet er bare nødvendig når du ikke bruker programmer fra "Polygon" -serien, dette programmet når det gjelder signering er identisk med programmene fra "Polygon" -serien, så det er ikke nødvendig; for å signere filer med programmer i "Polygon"-serien, se forrige side av instruksjonene; Du kan signere ved å bruke både "Polygon"-seriens programmer og CryptoARM-programmet, hvis du tror at dette vil være mer praktisk enn å bruke de eksisterende mulighetene til "Polygon"-seriens programmer;

    Hver fil (XML, skanning av trykt dokument og søknadsfiler) skal signeres, siden tinglysningsmyndigheten kun godtar par av filer: originalfilen og signaturfilen for denne. For å signere en fil, velg den i Utforsker-vinduet og klikk høyreklikk mus (RMB), vises kontekstmenyen, i den bør du velge "CryptoARM" -elementet, og deretter " Abonner...».



    Kontroller deretter at filnavnet er riktig



    Viktig! sett bryteren til posisjon " DER-koding", spesifiser mappen for utdatafilene etter eget skjønn. Trykk på knappen " Neste" Tilordne signaturparametere i neste vindu


    I dette vinduet er det viktigste å krysse av for " Lagre signatur i en egen fil" Klikk på knappen Neste" I neste vindu klikker du på knappen Velge»


    et sertifikatvalgvindu åpnes


    i den velger du sertifikatet til nøkkelen din (se etter eierens navn). Etter å ha valgt, klikk på knappen OK"Og" Neste" I det siste vinduet før du signerer dokumentet, klikker du på " Ferdig».

    Viktig! For hver fil er det nødvendig å lage en signaturfil, siden bare et par godtas: den opprinnelige filen (xml eller annet) + en signatur for den (sig-fil).