Informasjonssikkerhet for åpne kommunikasjonskanaler. Nøkkeldistribusjonsprotokoll

Legg igjen en kommentar 6,950

Kerberos-protokollen

Autentiseringsprotokoller:

3. Autentisering med en offentlig nøkkel

DSA-beskrivelse

p = primtall av lengde L-biter, der L er et multiplum av 64, fra 512 til 1024.

q = 160-bit primtall - faktor p-1

g = , hvor h er et hvilket som helst tall mindre enn p-1 for hvilket mer enn 1

x = tall mindre enn q

En enveis hash-funksjon brukes: H (m).

De tre første parameterne, p, q, g, er offentlige og kan deles av nettverksbrukere. Den private nøkkelen er x og den offentlige er y. For å signere en melding, m:

1. A genererer et tilfeldig tall k, mindre enn q

2. A genererer

Signaturen er parametrene r og s, den sender dem til

3. B verifiserer signaturen ved å beregne

Hvis v = r, er signaturen riktig.

Sammendrag

IPSec-standardsystemet inkluderer progressive teknikker og fremskritt innen nettverkssikkerhet. IPSec er en solid leder i settet med standarder for å bygge VPN-er. Dette tilrettelegges av den åpne konstruksjonen, som er i stand til å inkludere alle nye fremskritt innen kryptografi. IPsec beskytter nettverket ditt mot de fleste nettverksangrep ved å forkaste fremmede pakker før de når IP-nivået på den mottakende datamaskinen. Bare pakker fra registrerte interopspartnere kan gå inn på den beskyttede datamaskinen eller nettverket.

IPsec gir:

  • Autentisering - bevis på at pakkene ble sendt av din interaksjonspartner, det vil si eieren av den delte hemmeligheten;
  • integritet - umuligheten av å endre dataene i pakken;
  • konfidensialitet - umuligheten av å avsløre de overførte dataene;
  • pålitelig nøkkeladministrasjon - IKE-protokollen beregner en delt hemmelighet som kun er kjent for mottakeren og avsenderen av pakken;
  • tunneling - fullstendig maskering av bedriftens LAN-topologi

Arbeid innenfor rammen av IPSec-standarder gir fullstendig beskyttelse av informasjonsflyten fra avsender til mottaker, og blokkerer trafikk for observatører ved mellomliggende nettverksnoder. VPN-løsninger basert på IPSec-protokollstabelen sikrer bygging av virtuelle beskyttede nettverk, sikker drift og integrasjon med åpne kommunikasjonssystemer.

Beskyttelse på applikasjonsnivå

SSL-protokoll

Secure Socket Layer (SSL)-protokollen, utviklet av Netscape Communications i samarbeid med RSA Data Security, er designet for å muliggjøre sikker kommunikasjon i klient-/serverapplikasjoner. I praksis er SSL utbredt implementert bare i forbindelse med HHTP-applikasjonslagsprotokollen.

Sikkerhetsfunksjoner levert av SSL:

  • datakryptering for å forhindre avsløring av konfidensielle data under overføring;
  • signering av data for å forhindre avsløring av konfidensielle data under overføring;
  • klient- og serverautentisering.

SSL bruker kryptografiske metoder for å beskytte informasjon for å sikre sikkerheten ved informasjonsutveksling. Denne protokollen utfører gjensidig autentisering, sikrer konfidensialitet og autentisitet til overførte data. Kjernen i SSL-protokollen er en teknologi for kompleks bruk av symmetriske og asymmetriske kryptosystemer. Gjensidig autentisering av partene utføres ved å utveksle digitale sertifikater for klientens og serverens offentlige nøkler, digitalt signert av spesielle sertifiseringssentre. Konfidensialitet sikres ved å kryptere de overførte dataene ved hjelp av symmetriske sesjonsnøkler som partene utveksler når de oppretter en forbindelse. Ektheten og integriteten til informasjonen sikres gjennom dannelse og verifisering av en digital signatur. De asymmetriske krypteringsalgoritmene er RSA og Diffie-Hellman.

Figur 9 Kryptobeskyttede tunneler basert på SSL-protokollen

I henhold til SSL-protokollen opprettes kryptobeskyttede tunneler mellom endepunktene til det virtuelle nettverket. Klienten og serveren kjører på datamaskiner ved endepunktene av tunnelen (Figur 9)

SSL-samtaleprotokollen har to hovedstadier i dannelsen og vedlikeholdet av en sikker tilkobling:

  • etablere en SSL-sesjon;
  • sikker kommunikasjon.

Det første trinnet utarbeides før direkte beskyttelse av informasjonsutveksling og utføres ved hjelp av Handshake Protocol, som er en del av SSL-protokollen. Når du kobler til på nytt, er det mulig å generere nye sesjonsnøkler basert på den gamle delte hemmeligheten.

I prosessen med å etablere en SSL-økt løses følgende oppgaver:

  • autentisering av partene;
  • forhandling av kryptografiske og komprimeringsalgoritmer som skal brukes i sikker informasjonsutveksling;
  • dannelse av en delt hemmelig hovednøkkel;
  • generering av delte hemmelige sesjonsnøkler basert på den genererte hovednøkkelen for kryptografisk beskyttelse av informasjonsutveksling.

Figur 10 Klientserverautentiseringsprosess

SSL gir to typer autentisering:

  • serverautentisering av klient;
  • klientautentisering av serveren.

Klient-/serverprogramvare som støtter SSL kan bruke standard offentlig nøkkelkryptering for å bekrefte at server-/klientsertifikatet og den offentlige nøkkelen er gyldige og utstedt av en pålitelig kilde. Et eksempel på prosessen med å autentisere en klient med en server er vist i figur 10.

Protokollsøknadsordning

Før du sender en melding over en datalinje, går meldingen gjennom følgende behandlingsstadier:

1. Meldingen er fragmentert i blokker egnet for behandling;

2. Data komprimeres (valgfritt);

3. MAC-nøkkelen er generert;

4. Data krypteres ved hjelp av en nøkkel;

1. Ved hjelp av nøkkelen dekrypteres dataene;

2. MAC-nøkkelen er sjekket;

3.Datadekompresjon oppstår (hvis komprimering ble brukt);

4. Meldingen settes sammen fra blokker og mottakeren leser meldingen.

Autentisk nøkkeldistribusjon

EN, kunde CA Verifikasjonssenter B, Server
Generering av et nøkkelpar med digital signatur: ... Overfør til CA - symmetrisk krypteringsskjema; - åpen krypteringsordning; - CPU-krets; - alle funksjoner (bedre ONF) Generering av et nøkkelpar av et offentlig krypteringsskjema: ... Overfør til CA
K- tilfeldig øktnøkkel.

Hvis , deretter K akseptert som autentisk delt hemmelighet

Arbeidsfase

EN B

Symmetrisk krypteringsskjema
. . . etc. . . .

SSL-angrep

Som andre protokoller er SSL utsatt for angrep relatert til upålitelig programvaremiljø, injisering av bokmerkeprogrammer, etc.

  • Responsangrep. Den består i at en angriper registrerer en vellykket kommunikasjonsøkt mellom klienten og serveren. Senere etablerer den en tilkobling til serveren ved å bruke de innspilte meldingene fra klienten. Men med en unik "nonce"-tilkoblingsidentifikator, beseirer SSL dette angrepet. Kodene for disse identifikatorene er 128 bits lange, og derfor må en angriper skrive ned 2 ^ 64 identifikatorer for 50 % sjanse for å gjette. Antallet oppføringer som kreves og den lave sannsynligheten for å gjette gjør dette angrepet meningsløst.
  • Handshake-protokollangrep. En angriper kan prøve å påvirke håndtrykkprosessen for at partene skal kunne velge forskjellige krypteringsalgoritmer. Fordi mange implementeringer støtter eksportert kryptering, og noen til og med støtter 0-kryptering eller MAC, er disse angrepene av stor interesse. For å implementere et slikt angrep, må en angriper forfalske én eller flere håndtrykkmeldinger. Hvis dette skjer, vil klienten og serveren beregne forskjellige hash-verdier for håndtrykkmeldingen. Som et resultat av dette vil ikke partene godta «ferdige» meldinger fra hverandre. Uten å vite hemmeligheten, ville ikke en angriper kunne fikse "ferdig"-meldingen, slik at angrepet kunne oppdages.
  • Avsløring av chiffer. SSL er avhengig av flere kryptografiske teknologier. RSA offentlig nøkkelkryptering brukes for overføring av sesjonsnøkler og klient-/serverautentisering. Ulike kryptografiske algoritmer brukes som øktchiffer. Når disse algoritmene er vellykket angrepet, kan SSL ikke lenger betraktes som sikker. Angrep mot spesifikke kommunikasjonsøkter kan gjøres ved å ta opp økten og deretter forsøke å bruttforce sesjonsnøkkelen eller RSA-nøkkelen. Hvis det lykkes, vil det være mulig å lese den overførte informasjonen.
  • En angriper i midten. Et man-in-the-Middle-angrep involverer tre sider: klienten, serveren og angriperen. En angriper i mellom kan avskjære utvekslingen av meldinger mellom klienten og serveren. Angrepet er effektivt bare hvis Diffie-Halman-algoritmen brukes til nøkkelutveksling, siden integriteten til den mottatte informasjonen og dens kilde ikke kan verifiseres. Når det gjelder SSL, er et slikt angrep ikke mulig på grunn av at serveren bruker sertifikater sertifisert av en sertifiseringsmyndighet.

TLS-protokoll

Formålet med opprettelsen og fordeler

Målet med TLS er å forbedre SSL-sikkerheten og definere protokollen mer nøyaktig og fullstendig:

  • Mer robust MAC-algoritme
  • Mer detaljerte advarsler
  • Tydeligere definisjoner av gråsonespesifikasjoner

TLS tilbyr følgende avanserte sikkerhetsmetoder:

  • Nøkkelhashing for meldingsautentisering — TLS bruker hashing i meldingsidentifikasjonskoden (HMAC) for å forhindre at oppføringen endres når den går over et usikret nettverk som Internett. SSL versjon 3.0 støtter også meldingsautentisering med nøkler, men HMAC anses som sikrere enn MAC-funksjonen i SSL versjon 3.0.
  • Enhanced Pseudo-Random Function (PRF) PRF genererer nøkkeldata. I TLS er PRF definert ved hjelp av HMAC. PRF bruker to hashing-algoritmer for å sikre beskyttelsen. Hvis en av algoritmene er sprakk, vil dataene være beskyttet av den andre algoritmen.
  • Forbedret validering av Ferdig-meldingen - TLS 1.0 og SSL 3.0 sender en Ferdig-melding til begge endepunktene, noe som indikerer at den leverte meldingen ikke er endret. I TLS er imidlertid denne kontrollen basert på PRF- og HMAC-verdiene, som gir et høyere sikkerhetsnivå sammenlignet med SSL versjon 3.0.
  • Konsekvent sertifikathåndtering - I motsetning til SSL versjon 3.0, prøver TLS å spesifisere typen sertifikat som kan brukes av forskjellige TLS-implementeringer.
  • Spesielle varselmeldinger - TLS gir mer nøyaktige og fullstendige advarsler om problemer som oppstår i et av sluttsystemene. TLS inneholder også informasjon om når hvilke varselmeldinger skal sendes.

SSH-protokoll

Secure Shell (SSH)-protokollen er et sett med offentlige nøkkelautentiseringsprotokoller som lar en bruker på klientsiden trygt logge på en ekstern server.

Hovedideen med protokollen er at en bruker på klientsiden må laste ned en offentlig nøkkel fra en ekstern server og etablere en sikker kanal ved hjelp av en kryptografisk legitimasjon. Brukerens kryptografiske legitimasjon er passordet hans: det kan krypteres med den mottatte offentlige nøkkelen og overføres til serveren.

Alle meldinger er kryptert med IDEA.

SSH-protokollarkitektur

SSH utføres mellom to ikke-klarerte datamaskiner som kjører på et usikret nettverk (klient-server).

SSH-protokollpakken har tre komponenter:

  • SSH Transport Layer Protocol (SSH) gir serverautentisering. Den offentlige nøkkelen brukes til dette. Den første informasjonen for denne protokollen, både fra serversiden og fra klientsiden, er et par offentlige nøkler - "vertsnøkler". Den resulterende protokollen er en gjensidig autentisert sikker kanal som garanterer personvern og dataintegritet.
  • SSH brukerautentiseringsprotokoll. Kjører over enveisautentiseringskanalen etablert av SSH-transportprotokollen. For å utføre klient-til-server-autentisering støttes ulike enveisautentiseringsprotokoller. Disse protokollene kan bruke enten en offentlig nøkkel eller et passord. For eksempel kan de opprettes basert på en enkel passordautentiseringsprotokoll. Resultatet av protokollen er en gjensidig autentisert sikker kanal mellom serveren og brukeren. Følgende metoder brukes:

offentlig nøkkel- klienten får tilsendt en EDS, serveren sjekker tilliten til klientens offentlige nøkkel ved å bruke en kopi av nøkkelen som er tilgjengelig på serveren, og sjekker deretter klientens autentisitet ved å bruke Sc.

passord- klienten bekrefter sin autentisitet med et passord.

vertsbasert- i likhet med publickey, brukes bare et nøkkelpar for klientverten; etter å ha bekreftet autentisiteten til verten, stoler serveren på brukernavnet.

  • SSH Connection Protocol (SSH) kjører over en gjensidig autentisert sikker kanal etablert av tidligere protokoller. Protokollen sikrer driften av en sikker kanal samtidig som den deler den inn i flere sikre logiske kanaler.

Nøkkeldistribusjonsprotokoll

Protokollen inneholder 3 stadier. Det første trinnet er "Hello"-fasen, der den første identifikatoren er en streng, I, sendt for å starte protokollen, etterfulgt av en liste over støttede algoritmer, X.

På 2. trinn blir partene enige om hemmelig nøkkel, pkt. Til dette brukes Diffie-Hellman-algoritmen. Serveren bekrefter sin identitet ved å sende klientene sin offentlige nøkkel, verifisert av en digital signatur, , og signaturen til sammendraget, h. Siden er satt til h.

I trinn 3 brukes den hemmelige nøkkelen, sesjons-ID og sammendrag for å lage 6 "applikasjonsnøkler", beregnet med .

Sammendrag

Fordelene med protokollen inkluderer:

  • muligheten til å handle på en ende-til-ende-basis med implementering av TCP / IP-stabler, eksisterende APIer;
  • økt effektivitet sammenlignet med trege kanaler;
  • fraværet av problemer med fragmentering, bestemme det maksimale volumet av blokker som sendes langs en gitt rute;
  • en kombinasjon av komprimering og kryptering.

Opprettelse av en sikker dataoverføringskanal mellom distribuerte informasjonsressurser i en virksomhet

A. A. Terenin, Ph.D.,

Spesialist for kvalitetssikring av IT og programvare

Deutsche Bank Moskva

For øyeblikket må en stor bedrift med et nettverk av filialer i landet eller verden opprette et enkelt informasjonsrom og sikre klar koordinering av handlinger mellom sine filialer for å kunne drive forretninger.

For koordinering av forretningsprosesser som forekommer i forskjellige grener, er det nødvendig å utveksle informasjon mellom dem. Data som kommer fra ulike kontorer akkumuleres for videre behandling, analyse og lagring i et bestemt hovedkontor. Den akkumulerte informasjonen brukes deretter til å løse forretningsproblemer av alle grener av virksomheten.

Dataene som utveksles mellom tilknyttede selskaper er underlagt strenge krav til pålitelighet og integritet. I tillegg til dette skal data som utgjør forretningshemmeligheter holdes konfidensielt. For en fullverdig parallelldrift av alle kontorer bør informasjonsutvekslingen skje online (i sanntid). Det skal med andre ord etableres en permanent dataoverføringskanal mellom virksomhetens filialer og hovedkontoret. For å sikre uavbrutt drift av en slik kanal, stilles det krav om å opprettholde tilgjengeligheten til hver informasjonskilde.

La oss oppsummere kravene som må oppfylles av dataoverføringskanaler mellom grener av en bedrift for høykvalitets ytelse av oppgaven med å sikre konstant kommunikasjon:

    dataoverføringskanalen må være konstant,

    data som overføres over en slik kanal må opprettholde integritet, pålitelighet og konfidensialitet.

    I tillegg innebærer pålitelig drift av en permanent kommunikasjonskanal at lovlige brukere av systemet vil ha tilgang til informasjonskilder når som helst.

I tillegg til distribuerte bedriftssystemer som opererer i sanntid, finnes det off-line systemer. Datautveksling i slike systemer skjer ikke konstant, men etter spesifiserte tidsperioder: én gang daglig, én gang i timen osv. Data i slike systemer akkumuleres i separate filialdatabaser (DB), samt i sentrale databaser, og kun data fra disse databasene anses som gyldige.

Men selv om utveksling av informasjon bare skjer én gang om dagen, er det nødvendig å etablere en sikker dataoverføringskanal, som alle de samme kravene stilles for å sikre pålitelighet, integritet og konfidensialitet, samt tilgjengelighet for varigheten av kanalens drift.

Kravet om autentisitet betyr levering av autorisert tilgang, autentisering av partene i samhandlingen og utillateligheten av nektelse av forfatterskap og faktumet av dataoverføring.

Det stilles strengere krav til systemer for å sikre sikkerheten til informasjonstransaksjoner i et distribuert informasjonsmiljø, men dette er et tema for en egen artikkel.

Hvordan gi en slik beskyttelse av dataoverføringskanalen?

Det er mulig å koble hver gren til hver gren med en fysisk dataoverføringskanal (eller kun alle grener til senteret) og sikre umuligheten av tilgang til det fysiske mediet for overføring av informasjonssignaler. Ja, en slik løsning kan være akseptabel for implementering innenfor et enkelt beskyttet anlegg, men vi snakker om distribuerte bedriftssystemer, hvor avstanden mellom interaksjonsobjekter kan måles i tusenvis av kilometer. Kostnaden ved å implementere en slik plan er så høy at den aldri vil være kostnadseffektiv.

Et annet alternativ er å leie eksisterende, allerede anlagte kommunikasjonskanaler eller satellittkanaler fra teleoperatører. En slik løsning er også inkludert i kategorien dyre; dessuten vil beskyttelsen av disse kanalene kreve implementering eller installasjon av spesiell programvare (programvare) for hver av de samhandlende partene.

En svært utbredt, rimelig og effektiv løsning er organisering av sikre kommunikasjonskanaler over World Wide Web.

Nå er det vanskelig å forestille seg en organisasjon som ikke har tilgang til Internett og ikke bruker World Wide Web til å organisere sine forretningsprosesser. I tillegg er informasjonsteknologimarkedet mettet med nettverksutstyr og programvare fra ulike produsenter med innebygd informasjonssikkerhetsstøtte. Det er standarder, sikre nettverksprotokoller, som danner grunnlaget for de opprettede maskin- og programvareproduktene som brukes til å organisere sikker interaksjon i et åpent informasjonsnettverk.

La oss vurdere i detalj hvordan du kan lage sikre dataoverføringskanaler over Internett.

Problemene med sikker dataoverføring over åpne nettverk er mye diskutert i populær og masselitteratur:

World Wide Web utvides stadig, midlene for å overføre og behandle data utvikles, utstyr for å avskjære overførte data og tilgang til konfidensiell informasjon blir mer og mer perfekt. For tiden blir problemet med å sikre beskyttelse av informasjon mot uautorisert kopiering, ødeleggelse eller modifikasjon, under lagring, behandling og overføring gjennom kommunikasjonskanaler, mer og mer påtrengende.

Beskyttelse av informasjon under overføring over åpne kommunikasjonskanaler ved hjelp av asymmetrisk kryptering vurderes i, og problemene og løsningene ved bruk av en elektronisk digital signatur - inn.

Denne artikkelen diskuterer i detalj metodene for å sikre informasjonssikkerhet ved overføring av hemmelige data over åpne kommunikasjonskanaler.

For å beskytte informasjon som overføres over offentlig tilgjengelige kommunikasjonskanaler, brukes mange sikkerhetstiltak: data krypteres, pakker tilføres ytterligere kontrollinformasjon, en datautvekslingsprotokoll med økt grad av sikkerhet brukes.

Før du bestemmer deg for hvordan du skal beskytte de overførte dataene, er det nødvendig å tydelig skissere spekteret av mulige sårbarheter, liste opp metodene for avskjæring, forvrengning eller ødeleggelse av data, metoder for å koble til kommunikasjonskanaler. Svar på spørsmålene om hvilke mål angriperne forfølger og hvordan de kan bruke eksisterende sårbarheter for å implementere planene sine.

Ytterligere krav til den implementerte beskyttende dataoverføringskanalen inkluderer:

    identifikasjon og autentisering av samhandlende parter;

    prosedyren for beskyttelse mot substitusjon av en av partene (bruk av kryptoalgoritmer med en offentlig nøkkel);

    kontroll over integriteten til de overførte dataene, informasjonsoverføringsruten og beskyttelsesnivået til kommunikasjonskanalen;

    konfigurere og kontrollere kvaliteten på kommunikasjonskanalen;

    komprimering av overført informasjon;

    oppdagelse og korrigering av feil under dataoverføring over kommunikasjonskanaler;

    revisjon og registrering av arrangementer;

    automatisk gjenoppretting av arbeidskapasitet.

La oss bygge en modell av en inntrenger og en modell av en beskyttet gjenstand (fig. 1).

Algoritme for etablering av tilkobling

For å implementere en sikker dataoverføringskanal, brukes en klient-server-interaksjonsmodell.

To sider vurderes: serveren og klienten - en arbeidsstasjon som ønsker å etablere en forbindelse med serveren for videre arbeid med den.

I utgangspunktet er det bare to nøkler: serverens offentlige og private nøkler ( OKS og ZKS), og den offentlige nøkkelen til serveren er kjent for alle og overføres til klienten når han kontakter serveren. Serverens private nøkkel holdes strengt konfidensielt på serveren.

Klienten fungerer som initialisator av forbindelsen; den får tilgang til serveren gjennom et hvilket som helst globalt nettverk som denne serveren fungerer med, oftest via Internett.

Hovedoppgaven ved initialisering av en tilkobling er å etablere en datautvekslingskanal mellom to samhandlende parter, forhindre muligheten for forfalskning og forhindre situasjonen med brukerforfalskning, når en tilkobling opprettes med en bruker, og deretter kobler et annet medlem av systemet til den ene siden av kanalen og begynner å tildele meldinger beregnet på den lovlige brukeren, eller sende meldinger på vegne av noen andre.

Det er nødvendig å sørge for muligheten for å koble til en inntrenger når som helst og å gjenta håndtrykkprosedyren med visse tidsintervaller, hvis varighet må settes til minimum fra den tillatte.

Basert på antakelsen om at ZKS og OKS allerede opprettet, og OKS kjent for alle, men ZKS- bare til serveren får vi følgende algoritme:

1. Klienten sender en tilkoblingsforespørsel til serveren.

2. Serveren starter applikasjonen ved å sende en spesiell melding til den forespurte stasjonen for den forhåndsinstallerte klientapplikasjonen, der serverens offentlige nøkkel er hardkodet.

3. Klienten genererer nøklene sine (offentlige og private) for å jobbe med serveren ( JCC og ZKK).

4. Klienten genererer en øktnøkkel ( KS) (symmetrisk meldingskrypteringsnøkkel).

5. Klienten overfører følgende komponenter til serveren:

    klientens offentlige nøkkel ( JCC);

    øktnøkkel;

    tilfeldig melding (la oss kalle det NS), kryptert med serverens offentlige nøkkel ved hjelp av algoritmen RSA.

6. Serveren behandler den mottatte meldingen og sender en melding som svar NS kryptert med øktnøkkelen (symmetrisk kryptering) + kryptert med klientens offentlige nøkkel (asymmetrisk kryptering, for eksempel RSA) + signert med serverens private nøkkel ( RSA, DSA, GOST) (det vil si at hvis vi mottar X igjen på klientsiden etter dekryptering, betyr dette at:

    meldingen kom fra serveren (signatur - ZKS);

    serveren godtok vår JCC(og kryptert med vår nøkkel);

    server akseptert KS(Jeg krypterte meldingen med denne nøkkelen).

7. Klienten godtar denne meldingen, verifiserer signaturen og dekrypterer den mottatte teksten. Hvis vi, som et resultat av alle de omvendte handlingene, mottar en melding som er helt identisk med meldingen sendt til serveren NS, da anses det at den sikre datautvekslingskanalen er riktig installert og er helt klar til å fungere og utføre funksjonene sine.

8. I fremtiden begynner begge parter å utveksle meldinger som er signert med avsenderens private nøkler og kryptert med øktnøkkelen.

Et diagram over er vist i fig. 2.

Algoritme for å klargjøre en melding for sending til en sikker kanal

Uttalelsen av problemet er som følger: den originale (vanlige) teksten mottas ved inngangen til algoritmen, ved utgangen, ved hjelp av kryptografiske transformasjoner, mottar vi en lukket og signert fil. Hovedoppgaven som er tildelt denne algoritmen er å sikre sikker overføring av tekst, for å sikre beskyttelse i en ubeskyttet kanal.

Det er også nødvendig å introdusere muligheten til å forhindre avsløring av informasjon når en melding blir fanget opp av en angriper. Nettverket er åpent, alle brukere på dette nettverket kan fange opp alle meldinger som sendes over datalinken. Men takket være beskyttelsen som er iboende i denne algoritmen, vil dataene som angriperen har oppnådd, være helt ubrukelige for ham.

Naturligvis er det nødvendig å sørge for muligheten for åpning med brute-force, men da er det nødvendig å ta hensyn til tiden brukt på åpningen, som er beregnet på kjent måte, og bruke passende nøkkellengder som garanterer ikke-utlevering av informasjonen de lukker innen et gitt tidsrom.

Det er også en mulighet for at en angriper som har erstattet en juridisk representant har havnet i den andre enden av kanalen (på mottakersiden). Takket være denne algoritmen vil en melding som lett kan falle i hendene på en slik angriper også vise seg å være "uleselig", siden spooferen ikke kjenner de offentlige og private nøklene til den erstattede parten, så vel som øktnøkkelen .

Algoritmen kan implementeres som følger (fig. 3):

    kildeteksten er komprimert ved hjelp av ZIP-algoritmen;

    parallelt med denne prosessen signeres originalteksten med mottakerens offentlige nøkkel;

    den komprimerte teksten er kryptert med en symmetrisk sesjonsnøkkel, denne nøkkelen er også på mottakersiden;

    en digital signatur legges til den krypterte og komprimerte teksten som unikt identifiserer avsenderen;

    meldingen er klar til å sendes og kan sendes over kommunikasjonskanalen.

Algoritme for meldingsbehandling ved mottak fra en sikker kanal

En kryptert, komprimert og signert tekst kommer til inngangen til algoritmen, som vi mottar over kommunikasjonskanalen. Algoritmens oppgave er å skaffe, ved hjelp av omvendte kryptografiske transformasjoner, den originale klarteksten, for å verifisere autentisiteten til meldingen og dens forfatterskap.

Siden hovedoppgaven til systemet er å skape en sikker kanal på ubeskyttede kommunikasjonslinjer, gjennomgår hver melding sterke endringer og bærer med seg den tilhørende kontroll- og styringsinformasjonen. Prosessen med omvendt gjenoppretting av originalteksten krever også ganske lang transformasjonstid og bruker moderne kryptografiske algoritmer som bruker operasjoner med svært store tall.

Hvis du ønsker å gi maksimal beskyttelse for å sende en melding over en sikker kanal, må du ty til ganske langsiktige og ressurskrevende operasjoner. Mens vi øker graden av sikkerhet, taper vi i behandlingshastigheten for videresendte meldinger.

I tillegg er det nødvendig å ta hensyn til tids- og maskinkostnadene for å opprettholde påliteligheten til kommunikasjonen (kontrollere partene til hverandre) og for å utveksle kontroll- og styringsinformasjon.

Algoritme for meldingsbehandling ved mottak fra en sikker kanal (fig. 4):

    en digital signatur trekkes ut fra den mottatte krypterte, komprimerte og signerte meldingen;

    tekst uten digital signatur dekrypteres med øktnøkkelen;

    den dekodede teksten går gjennom dekompresjonsprosedyren ved hjelp av for eksempel ZIP-algoritmen;

    teksten oppnådd som et resultat av de to foregående operasjonene brukes til å bekrefte den digitale signaturen til meldingen;

    ved utgangen av algoritmen har vi den originale åpne meldingen og resultatet av signaturverifisering.

Meldingssignaturalgoritme

La oss vurdere mer detaljert meldingssignaturalgoritmen. Vi vil gå ut fra at alle offentlige og private nøkler til begge parter som utveksler data allerede er generert og private nøkler er lagret av deres direkte eiere, og offentlige nøkler har blitt sendt til hverandre.

Siden kildeteksten kan ha en ubegrenset og ikke-konstant størrelse hver gang, og den digitale signaturalgoritmen krever en datablokk av en viss konstant lengde for driften, vil hashverdien fra denne teksten bli brukt til å konvertere hele teksten til dens visning av en forhåndsbestemt lengde. Som et resultat får vi visningen av teksten på grunn av hovedegenskapen til hash-funksjonen: den er enveis, det vil ikke være mulig å gjenopprette den opprinnelige teksten fra den resulterende visningen. Algoritmisk er det umulig å finne noen slik tekst der verdien av hash-funksjonen vil falle sammen med den tidligere funnet. Dette tillater ikke en angriper fritt å erstatte en melding, siden verdien av hash-funksjonen vil endres umiddelbart, og den bekreftede signaturen vil ikke samsvare med standarden.

For å finne verdien av hash-funksjonen kan du bruke de velkjente hash-algoritmene ( SHA, MD4, MD5, GOST og andre), som lar deg få en datablokk med fast lengde ved utgangen. Det er med denne blokken at den digitale signaturalgoritmen vil fungere. Som en algoritme for en elektronisk digital signatur kan du bruke algoritmene DSA, RSA, ElGamal og så videre.

La oss beskrive meldingssignaturalgoritmen punkt for punkt (fig. 5):

    inngangen til den generelle algoritmen er en kildetekst av hvilken som helst lengde;

    verdien av hash-funksjonen beregnes for den gitte teksten;

    EDS;

    ved å bruke de mottatte dataene, beregnes verdien EDS hele teksten;

    ved utgangen av algoritmen har vi en digital signatur av meldingen, som går videre for å bli med i informasjonspakken som sendes til datautvekslingskanalen.

Signaturverifiseringsalgoritme

Algoritmen mottar to komponenter: den originale teksten til meldingen og dens digitale signatur. Dessuten kan kildeteksten ha en ubegrenset og ikke-konstant størrelse hver gang, og en digital signatur har alltid en fast lengde. Denne algoritmen finner hash-funksjonen til teksten, beregner den digitale signaturen og sammenligner den med informasjonen som mottas som input.

Ved utgangen av algoritmen har vi resultatet av å sjekke den digitale signaturen, som bare kan ha to verdier: "Signaturen samsvarer med originalen, teksten er ekte" eller "signaturen til teksten er feil, integriteten, autentisiteten eller forfatterskapet til meldingen er mistenkelig." Verdien ved utgangen av denne algoritmen kan deretter brukes videre i det sikre kanalstøttesystemet.

La oss beskrive algoritmen for å verifisere meldingssignaturen trinn for trinn (fig. 6):

    inngangen til den generelle algoritmen er en kildetekst av hvilken som helst lengde og en digital signatur av denne teksten med en fast lengde;

    verdien av hash-funksjonen fra den gitte teksten beregnes;

    den resulterende visningen av teksten med en fast lengde går inn i neste blokk med algoritmisk behandling;

    en digital signatur sendes til samme blokk, som kom til inngangen til den generelle algoritmen;

    Dessuten mottas en hemmelig (privat) nøkkel ved inngangen til denne blokken (beregning av en digital signatur), som brukes til å finne EDS;

    ved å bruke de mottatte dataene, beregnes verdien av den elektroniske digitale signaturen til hele teksten;

    vi mottok en digital signatur av meldingen, sammenlignet med EDS mottatt ved inngangen til den generelle algoritmen, kan vi trekke konklusjoner om påliteligheten til teksten;

    ved utgangen av algoritmen har vi resultatet av å sjekke den digitale signaturen.

Mulige angrep på den foreslåtte ordningen for implementering av en sikker kommunikasjonskanal

La oss vurdere de vanligste eksemplene på mulige angrep på en sikker dataoverføringskanal.

Først er det nødvendig å bestemme hva og hvem som kan stole på, for hvis du ikke stoler på noen eller noe, er det ingen vits i å skrive slike programmer for å støtte datautveksling over det globale nettverket.

Vi stoler på oss selv og programvaren som er installert på arbeidsstasjonen.

Når vi bruker en nettleser (Internet Explorer eller Netscape Navigator) for å kommunisere med en server, stoler vi på den nettleseren og stoler på at den bekrefter sertifikatene til nettstedene vi besøker.

Etter å ha bekreftet signaturen på appleten, kan du stole på OKS, som er innebygd i data eller programmer (appleter) lastet ned fra serveren.

Besittende OKS, som vi stoler på, kan du fortsette å jobbe videre med serveren.

Hvis systemet er bygget med klientapplikasjoner, må du stole på den installerte klientprogramvaren. Deretter, etter en kjede som ligner på det ovenfor, kan vi stole på serveren som forbindelsen er etablert med.

Mulige angrep.

1. Ved overføring OKS... Den er i prinsippet tilgjengelig for alle, så det vil ikke være vanskelig for en angriper å avskjære den. Besittende OKS, er det teoretisk mulig å beregne ZKS... Det er nødvendig å bruke kryptografiske nøkler av tilstrekkelig lengde for den angitte konfidensialitetstiden.

2. Etter overføring fra serveren OKS og før klienten sender tilbake sitt JCC og KS... Hvis i løpet av deres generasjon ( JCC, ZKK og KS) en svak tilfeldig tallgenerator brukes, kan du prøve å forutsi alle tre av de spesifiserte parameterne eller en av dem.

For å motvirke dette angrepet er det nødvendig å generere tilfeldige tall som oppfyller en rekke krav. Du kan for eksempel ikke bruke en timer til å generere tilfeldige tall, siden en angriper har fanget opp den første meldingen ( OKS fra serveren), kan angi tidspunktet for sending av pakken med en nøyaktighet på sekunder. Hvis tidtakeren går av hvert millisekund, kreves et fullstendig søk på bare 60 000 verdier (60 s _ 1000 ms) for et angrep.

For å generere tilfeldige tall, er det nødvendig å bruke parametere som er utilgjengelige for angriperen (hans datamaskin), for eksempel prosessnummeret eller andre systemparametere (som identifikasjonsnummeret til beskrivelsen).

3. Ved overføring fra klienten til serveren en pakke som inneholder JCC, KS, NS kryptert OKS... For å åpne den avlyttede informasjonen må du ha ZKS... Dette angrepet er redusert til angrepet vurdert ovenfor (utvalg ZKS). I seg selv er privat informasjon som overføres til serveren ubrukelig for en angriper.

4. Når du overfører en testmelding fra serveren til klienten NS kryptert KS og JCC og signert ZKS... For å dekryptere en avlyttet melding, må du vite og JCC, og KS, som vil være kjent i tilfelle implementering av et av angrepene ovenfor etter at fienden har blitt oppmerksom ZKS.

Men dekrypteringen av testmeldingen er ikke så skummel, en mye større fare er muligheten for å forfalske den overførte meldingen, når en angriper kan etterligne serveren. For å gjøre dette, må han vite det ZKSå signere pakken riktig, og alle nøkler KS og JCC som selve meldingen NS for å gjøre opp den falske posen riktig.

Hvis noen av disse punktene brytes, anses systemet som kompromittert og ute av stand til ytterligere å sikre sikker drift av klienten.

Så vi undersøkte angrepene som er mulige på stadiet for implementering av HandShake-prosedyren. La oss beskrive angrepene som kan utføres under overføring av data gjennom kanalen vår.

Ved avskjæring av informasjon kan en angriper bare lese klarteksten hvis han vet det KS... En angriper kan forutsi eller velge den ved å oppgi alle mulige verdier fullstendig. Selv om motstanderen kjenner meldingen (det vil si at han vet nøyaktig hvordan klarteksten ser ut, tilsvarende koden han fanget opp), vil han ikke være i stand til entydig å etablere krypteringsnøkkelen, siden denne teksten ble utsatt for en komprimeringsalgoritme .

Det er heller ikke mulig å bruke et sannsynlig ord pull-angrep, da hver melding vil se annerledes ut i hver melding. På grunn av at informasjon blandes under arkivering, i likhet med det som gjøres ved beregning av verdien av en hash-funksjon, påvirker den forrige informasjonen hvordan neste blokk med data vil se ut.

Det følger av det som er beskrevet at en angriper i alle fall bare kan bruke et angrep basert på et uttømmende søk av alle mulige nøkkelverdier. For å øke motstanden mot denne typen angrep er det nødvendig å utvide verdiområdet KS... Med en 1024-bits nøkkel øker utvalget av mulige verdier til 2 1024.

For å skrive eller forfalske meldinger som sendes over en kommunikasjonskanal, må en angriper kjenne til de private nøklene til begge parter som deltar i utvekslingen, eller kjenne til en av de to private nøklene ( ZK). Men i dette tilfellet vil han bare kunne falske meldinger i én retning, avhengig av hvem ZK han vet. Han kan fungere som avsender.

Når han prøver å erstatte noen av partene, det vil si når han prøver å utgi seg for en juridisk deltaker i utvekslingen etter å ha etablert en kommunikasjonsøkt, må han vite KS og ZK(se sakene omtalt tidligere). Hvis ingen av delene KS heller ikke ZK Angriperen vet ikke hvem i stedet for hvem han vil koble til kommunikasjonskanalen, da vil systemet umiddelbart finne ut om dette, og videre arbeid med den kompromitterte kilden vil stoppe.

Helt i begynnelsen av arbeidet, når du kobler til en server, er et trivielt angrep mulig: erstatning av DNS-serveren. Det er ikke mulig å forsvare seg mot det. Løsningen på dette problemet er overlatt til administratorene av DNS-servere som drives av Internett-leverandører. Det eneste som kan lagres er den allerede beskrevne prosedyren for å sjekke nettstedets sertifikat av nettleseren, som bekrefter at tilkoblingen til riktig server har skjedd.

Konklusjon

Artikkelen diskuterer metoder for å bygge en sikker dataoverføringskanal for å sikre interaksjon mellom distribuerte bedriftsdatasystemer.

Det er utviklet en protokoll for å etablere og vedlikeholde en sikker tilkobling. Algoritmer for å sikre beskyttelse av dataoverføring foreslås. Mulige sårbarheter ved det utviklede samhandlingsopplegget analyseres.

En lignende teknologi for å organisere sikre tilkoblinger er organisert av SSL-nettverkskommunikasjonsprotokollen. I tillegg bygges virtuelle private nettverk (VPN-er) på grunnlag av de foreslåtte prinsippene.

LITTERATUR

1. Medvedovsky ID, Semyanov PV, Platonov VV Angrep på Internett. - SPb .: Forlag "DMK" 1999. - 336 s.

2. Carve A. Infrastruktur med offentlige nøkler. LAN / Journal of Network Solutions (russisk utgave), 8, 1997.

3. Melnikov Yu. N. Elektronisk digital signatur. Beskyttelsesevner. Confident nr. 4 (6), 1995, s. 35–47.

4. Terenin AA, Melnikov Yu. N. Opprettelse av en sikker kanal i nettverket. Materialer fra seminaret "Information Security - South of Russia", Taganrog, 28.-30. juni 2000.

5. Terenin A. A. Utvikling av algoritmer for å lage en sikker kanal i et åpent nettverk. Automatisering og moderne teknologi. - Forlaget "Mekanikkteknikk", nr. 6, 2001, s. 5-12.

6. Terenin A. A. Analyse av mulige angrep på en sikker kanal i et åpent nettverk, laget av programvare. Materialer fra XXII-konferansen for unge forskere ved fakultetet for mekanikk og matematikk ved Moscow State University, Moskva,17-22 april 2000.

I enhver organisasjons arbeid er det ofte behov for utveksling av konfidensiell informasjon mellom to eller flere personer. Den enkleste løsningen er å overføre den muntlig eller personlig i papirform. Men hvis dette ikke er mulig, samt om det er nødvendig å overføre informasjon i elektronisk form, brukes vanligvis kryptografiske transformasjoner. Til tross for den utbredte bruken, har kryptografi sine ulemper - faktumet med overføring er ikke skjult, og hvis krypteringsalgoritmen ikke er sterk nok, blir det mulig for en inntrenger å gjenopprette informasjon. I tillegg, på grunn av kompleksiteten til kryptografiske transformasjoner, pålegges det en begrensning på dataoverføringshastigheten, som kan være kritisk når man kringkaster store mengder dokumentar- eller multimedieinformasjon (video eller lyd) over en åpen kanal, for eksempel i en telekonferanse. modus.

Etter forfatternes mening kan et alternativ til kryptografiske transformasjoner i dette tilfellet være en integrert tilnærming til organisering av utveksling av konfidensiell informasjon, inkludert steganografiske transformasjoner (som involverer skjul av selve overføringen av konfidensiell informasjon) og bruk av ulike metoder for autentisering og nettverksbelastningsbalansering.

Hensikten med denne studien er å utvikle en metode for skjult overføring av informasjon i en videostrøm og implementering av den i form av en programvarepakke. Metodikken er basert på prioritering av trafikk til noen brukere i forhold til andre. I løpet av arbeidet ble det laget en proprietær trafikkkontrollalgoritme, som brukes i denne teknikken for å organisere en sikker utveksling av informasjon.

Mulige anvendelsesområder for algoritmen er nettverksbelastningsbalansering, privilegert tilgang til ressurser, organisering av en skjult meldingsoverføringskanal.

Følgende krav stilles til programvareimplementeringen av algoritmen:

Åpenhet for brukeren;

Feiltoleranse;

- sikker lagring av private nøkler og systemdata med begrenset tilgang;

Gjennomførbarhet av søknad, det vil si gevinst i hastighet, kvalitet på tjenesten eller sikkerhet;

Kompatibel med diverse nettverksutstyr.

La oss vurdere "Privilege Label"-algoritmen mer detaljert. I normal modus blir pakker overført direkte fra kilden til adressaten, utenom serveren. Dette er organisasjonens vanlige lokalnettverk. Før den tiltenkte starten av ad hoc-modus, starter administratoren tjenesten på serveren. Nettverket går i standby-modus.

Pakken mottas, det kontrolleres om det er et merke for begynnelsen av spesialmodusen, hvis det er en, utføres overgangen til spesialmodusen, ellers leveres pakken til adressaten og en ny mottas . Pakkestrukturen er vist i figur 1.

Spesialmodus. Autentiseringsinformasjonen til pakkeavsenderen kontrolleres. Serverens arbeid er tydelig vist i form av et blokkdiagram i figur 2.

Figur 3 viser opplegget for å sende pakker til adressaten. Alle pakker går gjennom serveren, hvor etiketten leses tilsvarende mottakeradressen. Hvis autentiseringen er vellykket, videresendes pakken til adressaten.

Klienten starter tjenesten på datamaskinen sin. Tjenesten sjekker om serveren kjører. Hvis serveren ikke kjører, logger programmet en registrering av feilen som har oppstått og bytter til kildedestinasjonsmodus. Hvis serveren kjører, sjekker den om det finnes en maskinvarenøkkel. Hvis det ikke er noen maskinvarenøkkel, registreres en feil og en retur til kildedestinasjonsmodus skjer. Hvis maskinvarenøkkelen er til stede, utføres overgangen til kilde-server- og destinasjonsserver-modusene.

I kilde-server- og destinasjonsserver-modus sendes meldinger som følger. Brukerinformasjon, rettighetsetikett og skjulte data legges til pakken. Pakken blir sendt. Mottak av meldinger utføres som følger: den mottatte meldingen skrives til bufferen; i henhold til tabellen over steganografiske transformasjoner, tildeles pakker med skjult informasjon; det er en samling av konfidensiell informasjon (fig. 4).

Metodikk for å organisere en sikker kanal

En sikker informasjonsoverføringskanal løser problemet med beskyttelse mot uautorisert tilgang til nettverksnoder som informasjon overføres mellom, og selve informasjonen i ferd med overføring over åpne kommunikasjonskanaler.

Basert på «Privilege Label»-algoritmen ble det utviklet en metode for å organisere en sikker informasjonsoverføringskanal med trafikkkontroll under overføring.

La oss vurdere trinnene som denne metoden for å utveksle konfidensiell informasjon for brukeren inkluderer.

1. En autentisering (elektronisk nøkkel) presenteres.

2. Hvis autentiseringen er vellykket, legges den nødvendige konfidensielle informasjonen inn i programmet.

3. Videokonferansen starter (og underveis sending av konfidensiell informasjon).

4. Under videokonferansen mottas og gjenkjennes også informasjon fra en annen deltaker i datautvekslingen.

5. Konferansen avsluttes.

For å organisere en sikker kanal må brukeren ha Privilege Label-programmet installert, en elektronisk nøkkel med autentiseringsdata, et webkamera og tilgang til nettverket for organisering av kommunikasjon.

Godkjenning

I denne teknikken brukes autentiseringsprosedyren for å autorisere operatør-bruker før du begynner å arbeide med klientprogramvaremodulen og for å bekrefte autentisiteten til meldingen med rettighetsetiketten som kom fra klienten til systemserveren.

Dermed kreves et ett-trinns autentiseringsskjema av maskinvarenøkkel og datafelt i TCP-pakkehodet. Den enkleste og mest effektive måten å løse dette problemet på vil være å bruke algoritmen for å beregne innsettingsimitasjonen i samsvar med GOST 28147-89, siden den gir høy kryptografisk styrke, lar deg variere lengden på autentiseringsfeltet i pakken, og er effektivt implementert på moderne maskinvareplattformer for generelle PC-er. I dette tilfellet, for å løse begge problemene, kan den samme nøkkelen brukes, lagret på nøkkelholderen presentert av operatøren. Når en bruker er autentisert til å gå inn i systemet (når klientapplikasjonen startes), sendes en testmelding til serveren, kryptert på nøkkelen fra den presenterte nøkkelbæreren. Hvis serveren var i stand til å dekryptere den med en nøkkel som tilsvarer den lovlige brukeren til den gitte verten, anses autentiseringen som bestått og serveren rapporterer dette til klientapplikasjonen.

Autentisering av overførte TCP-pakker utføres i henhold til standardskjemaet, når informasjonsfeltet til pakken er kryptert i modusen for beregning av det imiterende innlegget og lagt til autentiseringsfeltet, og serveren kontrollerer riktigheten av det beregnede imiterende innlegget ved å bruke krypteringsnøkkelen lagret i databasen.

Det skal bemerkes at for å sikre påliteligheten til et slikt opplegg med høy nettverksbelastning, må krypteringsnøkler for alle brukere endres minst en gang i måneden, som ved bruk av systemet når du arbeider i en organisasjons lokale nettverk er ikke vanskelig og løses med organisatoriske og administrative metoder.

Steganografi

Med steganografisk transformasjon må tillegget av beholdere skje i sanntid, og nøkkelstyrken må sikres.

Oftest brukes metoden med minst signifikante biter for å modifisere videotrafikk og bygge inn stegocontainere. Denne metoden er ikke motstandsdyktig mot forvrengning av informasjon som overføres i stegocontainere, for eksempel kan du nullstille alle de siste bitene, noe som vil ødelegge all konfidensiell informasjon. Du kan også gjenopprette skjult informasjon ved hjelp av statistiske mønstre.

Funksjonene ved bruken av steganografi i den utviklede teknikken for videokonferanser er som følger:

Stegocontainere er innebygd i sanntid;

Åpen overført informasjon er stor - belastningen på kanalen øker;

I stegocontainere er det nødvendig å overføre autentiseringstokener;

Å legge til beholdere må være gjennomsiktig for brukeren;

Autentisering bør være brukervennlig og automatisert;

Overføringen av autentiseringstokener må være kontinuerlig.

Pakkenummerinformasjon kan overføres på en rekke måter. Essensen av den første overføringsmetoden: den første pakken inkluderer en offset til neste pakke med konfidensiell informasjon, etc., det vil si at hver pakke med en stego-beholder i begynnelsen av datafeltet vil inneholde informasjon om nummeret til den neste pakke med en stego-beholder. Det er viktig at forskyvningen er spesifisert, ikke pakkenummeret, siden forskyvningskodingen generelt vil kreve færre biter.

I programinnstillingene må du bestemme hvor mange biter i begynnelsen av pakken som skal tildeles adressen til neste pakke. For eksempel, hvis avstanden mellom pakker ikke overstiger 100, må 7 biter tildeles for offsetkoding. Hver bit som tildeles for offset kan øke avstanden mellom pakker betydelig og dermed jevne ut de statistiske egenskapene til videostrømmen.

Ulempen med denne metoden er at ved å avskjære den første pakken, lærer angriperen nummeret på den neste pakken og kan dermed gradvis gjenopprette hele sekvensen.

Den andre overføringsmetoden er å skrive en tabell som inneholder antall pakker med konfidensiell informasjon til maskinvarenøklene før starten av videokonferansen. Alle trafikktransformasjoner skjer på klientmaskiner, og gir dermed ekstra sikkerhet, siden informasjon i klar form ikke går over nettverket.

Ulempen med denne metoden er at når en angriper skaffer seg en maskinvarenøkkel, kan han gjenopprette den overførte konfidensielle informasjonen.

Den tredje måten å overføre bordet på er å overføre det i et håndgripelig medium, for eksempel i papirform. Ulemper med denne metoden: klienten legger inn tabellen manuelt i programmet og muligheten for å avskjære nøkkelinformasjon av inntrengeren.

Programvareimplementering

La oss vurdere driften av et program som implementerer denne algoritmen. Det skal bemerkes at den består av klient- og serverdelen.

Klientdelen kjører i bakgrunnen og gir minimumssettet med funksjoner:

Delta i en videokonferanse;

Send konfidensiell informasjon til adressaten;

Godta og gjenkjenne konfidensiell informasjon.

Dessuten bør brukeren ikke tenke på å velge nødvendig skjult informasjon fra videostrømmen - innsamlingen av data fra forskjellige pakker skjer automatisk av klientdelen av applikasjonen. Denne prosessen utføres på klientmaskinen slik at informasjon ikke beveger seg i nettverket i det klare, siden hvis du gjenoppretter den på serveren og deretter overfører den, vil delen fra adressaten til serveren være potensielt farlig.

Serverdelen er ment for administratoren. Ved første start legger administratoren til IP-adressene til nettverket manuelt, og fortsetter deretter med å tildele etiketter. Et hakemerke settes ved siden av den privilegerte adressen. Administratoren angir også forskyvningsstørrelsen (antall biter som tildeles i begynnelsen av pakken), siden hvis det angis av klientsiden av applikasjonen, kan kollisjoner oppstå når forskyvningsstørrelsene for forskjellige brukere ikke stemmer overens.

Dermed utfører administratoren manuelt følgende handlinger:

Oppgi IP-adressen til videokonferansebrukerne;

Velge størrelsen på offset for adressen;

Tast inn brukernøkler for autentisering.

Tjenesteinformasjon som kreves for driften av programmet, konfidensiell informasjon og selve nøklene lagres både på serveren og på klientarbeidsstasjonene.

Serveren lagrer informasjon om brukerens maskinvarenøkler, brukerpassord, størrelsen på forskyvningene for adressen, IP-adressene til brukerne, samt startmerket for spesialmodusen.

Klientarbeidsstasjonen lagrer maskinvarenøkkelen, passordet, konfidensiell informasjon, informasjon om IP-adressene til andre deltakere i informasjonsutvekslingen.

Det skal bemerkes at grensesnittet til dette programmet ikke innebærer mange fine innstillinger. Programmet er utviklet for å gi administratoren en enkel oversikt over etiketttildelingen. Den vil utføre alle transformasjoner på pakkenivå på egen hånd.

Programmet forutsetter tilstedeværelsen av to typer brukere - klient og administrator.

Klienten, som bruker klientdelen av applikasjonen og autentiseringsverktøyet, er autorisert i systemet og får tilgang til videokonferansen, hvor han sender og mottar konfidensiell informasjon. Han har ikke tilgang til nettverksinnstillingene, han kjenner nøkkelen som han kan tildele stego-beholdere med og samle inn konfidensiell informasjon i sin opprinnelige tilstand.

Administratoren administrerer nettverksinnstillingene ved å bruke bakenden av applikasjonen. Den legger til og fjerner brukere, tillater IP-adresser, har ikke tilgang til konfidensiell informasjon som sådan, og kjenner ikke nøkkelen som kan brukes til å skille stegocontainere fra den generelle strømmen.

Programmet må støtte Windows og Linux operativsystemer. Det er viktig at systemet er på tvers av plattformer, da nettverket kan være heterogent, spesielt for eksterne brukere.

For å implementere "Privilege Labels"-algoritmen, er det nødvendig å endre overskriftene til TCP-pakker. Først ble RFC 793-spesifikasjonen (som beskriver strukturen til en TCP-pakke) studert og verktøyene ble valgt - PCAP- og libnet-bibliotekene. Begge bibliotekene er på tvers av plattformer. Med deres hjelp kan du lage ditt eget program som implementerer funksjonene til å behandle TCP-hoder.

Som en prototype ble det laget en tilpasset implementering av programmet som lar deg lage en socket enten i servertilstanden (venter på at klienten skal koble seg til) eller i klienttilstanden (prøver å koble til serveren). Resultatene av tidligere utvikling ved universitetet på relaterte temaer ble tatt i betraktning.

Det opprettede TCP-programmet gir en stabil tilkobling, pakker dannes uavhengig. Som et resultat er det mulig å legge til tilpasset informasjon i TCP-hodealternativfeltet. For å lage hovedprogrammet, gjenstår det å danne en server og en klient på denne prototypen, legge til et brukergrensesnitt, ta hensyn til kravene til standarder og forskrifter.

Serverens jobb er å videresende pakker til klienter. Du må angi en liste over IP-adresser som du kan koble til serveren fra. I tillegg må administratoren konfigurere konferanser og spesifisere klientene som skal delta i dem. Serverkonfigurasjonen settes i en tekstfil, og selve serveren startes som en konsollapplikasjon.

Avslutningsvis kan følgende konklusjoner trekkes. Hensikten med arbeidet - utvikling av en metodikk for å organisere en sikker kanal for overføring av konfidensiell informasjon ved å legge inn stegocontainere i en videostrøm - er oppnådd. En algoritme for å organisere en logisk kanal basert på rettighetsetiketter er utviklet, og autentiseringsmetoder er valgt. Krav til programvareimplementering ble definert. En mekanisme for steganografiske transformasjoner er opprettet. Generelt er arbeidet en algoritme for å prioritere trafikk "Etikett med privilegier", en liste over nødvendige komponenter for å organisere en sikker kanal, en metode for å bygge inn stegocontainere, en beskrivelse av kravene til programvareimplementering, den første versjonen av programvareproduktet . Det er planlagt å forbedre algoritmen ytterligere, legge til nye funksjoner og et mer brukervennlig grensesnitt, samt implementere alt det ovennevnte i form av en fullverdig programvarepakke.

Litteratur

1. Litvinenko V.A., Khovanskov S.A. Distribuert databehandling i et nettverk ved metoden for kollektiv beslutningstaking // Izv. SFedU. Teknisk vitenskap: tematisk. Problemstilling: Sikkerhet av telekommunikasjonssystemer. Taganrog: Forlag til TTI SFU, 2008. Nr. 3 (80). S. 110-113.

2. Sventusov S.V. Metoder for å redusere belastningen på lydkonferanseservere // Izv. SPbGEU (LETI), 2008. 2.S. 25-30.

3. Sheida V.V. Bruk av TCP- og UDP-protokoller for sikker overføring av informasjon over SSL-VPN-tunneler: Dokl. TSUSUR, 2010.S. 225-229.

4. Samuilov K.E. En metode for å løse problemet med å dele ressurser til et multitjenestenettverk mellom virtuelle private nettverk med unicast- og multicast-forbindelser // Vestn. RUDN. Ser .: Matematikk, informatikk, fysikk. 2010. nr. 2 (1). S. 42-53.

5. Antamoshkin A.N., Zolotarev V.V. Algoritme for beregning av predikert trafikk ved design av distribuerte systemer for behandling og lagring av informasjon // Vestn. SibGAU, Krasnoyarsk, 2006. Nr. 1. S. 5-10.

6. Bondar IV, Zolotarev VV, Popov AM. Metoder for å vurdere sikkerheten til et informasjonssystem i henhold til kravene i // Informatikk og kontrollsystemer. 2010. Utgave. 4 (26). S. 3-12.

14.09.2006 Mark Joseph Edwards

Hvilken metode er best for dine forhold? Å sende filer over Internett er en vanlig operasjon, og sikring av filene du overfører er av største betydning for mange virksomheter. Det finnes en rekke måter å overføre filer på og mange metoder for å beskytte disse filene under overføring.

Hvilken metode er best for dine forhold?

Å sende filer over Internett er en vanlig operasjon, og sikring av filene du overfører er av største betydning for mange virksomheter. Det finnes en rekke måter å overføre filer på og mange metoder for å beskytte disse filene under overføring. Valget av overførings- og krypteringsmetoder avhenger av avsenderens generelle behov. I noen tilfeller er det nok å bare sørge for sikkerheten til filene under overføringen. I andre er det viktigere å kryptere filene slik at de forblir beskyttet selv etter levering til adressaten. La oss se nærmere på måter å overføre filer på på en sikker måte.

På vei og ved ankomst

Hvis din eneste hensikt er å beskytte filer når de reiser over Internett, trenger du sikker transportteknologi. Et alternativ er å bruke et nettsted som kan motta filer lastet opp til det, og at slike filer kan lastes ned på en sikker måte. For å transportere filer sikkert til et nettsted, kan du opprette en Secure Sockets Layer (SSL)-webside som er vert for en ActiveX-kontroll eller Javascript-skript. Du kan for eksempel bruke AspUpload-kontrollen fra Persitis Software; Utviklerne hevder at det er "den mest avanserte sentrale filtransportkontrollen som er tilgjengelig på markedet." Et annet alternativ er å bruke Free ASP Upload-skriptet, som ikke krever en binær komponent. For ekstra sikkerhet kan du til og med passordbeskytte både nettsiden og dens tilknyttede katalog for hosting av innsendinger. Når det gjelder å laste ned filer fra et nettsted, må du bare sørge for at den tilsvarende webserveren gir SSL-tilkoblinger, i det minste for URL-en som brukes til å laste ned filene.

Et alternativ er å bruke en FTP-server som gir dataoverføring ved hjelp av FTP Secure-protokollen. I utgangspunktet er FTPS en FTP-protokoll som kjører over en SSL-sikret tilkobling. FTPS er tilgjengelig i mange populære FTP-klienter, men dessverre ikke i Microsofts FTP-tjeneste. Derfor må du bruke en FTP-serverapplikasjon som gir denne muligheten (for eksempel det populære WFTPD-produktet). Ikke forveksle FTPS med SSH File Transfer Protocol. SFTP er en filoverføringsprotokoll som kjører på toppen av Secure Shell (SSH); den kan også brukes til å overføre filer. Men husk at SFTP er inkompatibelt med tradisjonell FTP, så sammen med en sikker shell-server (f.eks. en server levert av SSH Communications Security), trenger du en spesiell SFTP-klient (dette kan være en klient inkludert i PuTTY Telnet / Secure Shell eller WinSCP med GUI).

I tillegg kan VPN-er gi sikre filoverføringer. Windows Server-plattformer gir VPN-interoperabilitet gjennom RRAS. Dette garanterer imidlertid ikke kompatibilitet med partnernes VPN-løsninger. Hvis denne kompatibiliteten ikke er tilgjengelig, kan du bruke en av de utbredte løsningene, for eksempel åpen kildekode Open-VPN-verktøyet. Den er gratis og kjører på en rekke plattformer, inkludert Windows, Linux, BSD og Macintosh OS X. For mer informasjon om OpenVPN-integrasjon, se Arbeide med OpenVPN ( ).

Når du har en VPN-tilkobling, vil du kunne tildele kataloger og overføre filer i begge retninger. Ved all bruk av VPN er trafikken kryptert, så det er ikke behov for ytterligere kryptering av filer – bortsett fra de tilfellene hvor det kreves at filene forblir beskyttet på systemet de overføres til. Dette prinsippet gjelder for alle overføringsmetodene jeg har nevnt så langt.

Hvis du ikke er bekymret for overføringsstadiet og ditt hovedanliggende er å hindre uautoriserte brukere fra å få tilgang til innholdet i filene, er det lurt å kryptere filene før du transporterer dem. I dette tilfellet er e-post sannsynligvis en effektiv filoverføringskanal. E-postapplikasjoner er installert på nesten alle stasjonære systemer, så hvis du sender filer på e-post, trenger du ikke bruke andre teknologier enn datakryptering. Metoden for overføring av e-postfil er effektiv fordi meldinger og vedlegg vanligvis går direkte til mottakerens postkasse, selv om meldingen kan passere gjennom flere servere under overføring.

Men hvis du fortsatt trenger ekstra beskyttelse for dataene dine når de går via e-post, bør du vurdere å bruke protokollene SMTP Secure (SMTPS) og POP3 Secure (POP3S). I utgangspunktet er SMTPS og POP3S vanlige SMTP- og POP3-protokoller, utført over en sikker SSL-tilkobling. Microsoft Exchange Server, som de fleste e-postklienter, inkludert Microsoft Outlook, gir muligheten til å bruke SMTPS- og POP3S-protokollene. Det bør huskes at selv i tilfeller der SMTPS brukes til å utveksle filer mellom e-postklienten og e-postserveren, er det fortsatt mulig for e-postserveren å levere e-post til den endelige mottakeren over en vanlig usikret SMTP-forbindelse.

Fordi e-postbehandlingsverktøy er så utbredt, vil resten av denne artikkelen fokusere på sikker overføring av filer over e-postkanaler. Når vi gjør det, vil vi gå ut fra det faktum at avsenderen må kryptere dataene for å beskytte dem både på overføringsstadiet og etter levering. Så la oss ta en titt på de mest populære e-postkrypteringsteknologiene i dag.

Verktøy for filkomprimering

Det er mange måter å komprimere filer til én enkelt arkivfil, og mange av de foreslåtte løsningene bruker en eller annen form for kryptering for å beskytte innholdet i arkivet. Vanligvis settes et passord under komprimeringsprosessen, og alle som ønsker å åpne arkivet kan bare gjøre det med dette passordet.

En av de mest populære metodene for å lage komprimerte filarkiver er zip-komprimeringsmetoden; nesten alle arkivere støtter det. Og et av de vanligste zip-komprimeringsverktøyene i dag er WinZip-applikasjonen. Det kan brukes som et frittstående program, innebygd i Windows Utforsker for enkel tilgang, og bruke WinZip Companion for Outlook for å integrere dette produktet med Outlook-klienten. WinZip, som mange andre zip-kompatible arkivere, gir Zip 2.0-kryptering. Men jeg må si at beskyttelse av filer ved hjelp av denne metoden ikke er pålitelig nok. Et mer akseptabelt krypteringsalternativ er implementert i WinZip 9.0-produktet. Som figur 1 viser, støtter WinZip nå Advanced Encryption Standard (AES) spesifikasjonen, som bruker 128-biters eller 256-biters krypteringsnøkler. AES er en relativt ny teknologi, men den regnes allerede som en industristandard.

Skjerm 1 WinZip støtter AES-spesifikasjoner

Jeg kan ikke si nøyaktig hvor mange arkivere som gir bruk av sterke krypteringsalgoritmer ved bruk av AES, og vil begrense meg til å nevne en slik applikasjon; Dette er et bxAutoZip-produkt utviklet av BAxBEx Software. Den fungerer sammen med BAxBEx CryptoMite og kan bygges inn i Outlook. Mens WinZip bare kan kryptere data ved hjelp av Zip 2.0 og AES, tilbyr CryptoMite en rekke andre krypteringsalternativer, inkludert de populære Twofish- og Blowfish-algoritmene, Cast 256, Gost, Mars og SCOP.

Nesten alle datasystemer er utstyrt med verktøy for å pakke ut zip-filer, men ikke alle zip-applikasjoner gir kompatibilitet med ulike krypteringsalgoritmer. Derfor, før du sender krypterte filer, må du sørge for at mottakerens zip-applikasjon "forstår" den valgte algoritmen.

Når du krypterer filer med zip-applikasjoner, brukes sikre passord. Mottakeren må også bruke det tilsvarende passordet for å dekryptere arkivfilen. Det må utvises forsiktighet når du velger en metode for levering av passord. Sannsynligvis de sikreste metodene for levering av passord er via telefon, faks eller bud. Du kan velge hvilken som helst av dem, men du bør ikke i noe tilfelle sende passordet på e-post i ren tekst; i dette tilfellet øker faren for at en uautorisert bruker får tilgang til den krypterte filen dramatisk.

Husk at krypterte arkivere muliggjør filoverføringer utover e-postkanaler. De kan effektivt brukes til datatransport og med de andre metodene nevnt ovenfor.

Ganske godt privatliv

En annen ekstremt populær krypteringsmetode kan implementeres med Pretty Good Privacy. PGP slo til da Phil Zimmerman først publiserte det gratis på Internett i 1991. PGP ble et kommersielt produkt i 1996 og ble deretter kjøpt opp av Network Associates (NAI) i 1997. I 2002 ble denne teknologien kjøpt opp fra NAI av det unge PGP Corporation.

Siden den gang har PGP Corporation solgt en kommersiell versjon av PGP som kjører på Windows og Mac OS X. Den nåværende versjonen av PGP 9.0, som implementerer enkeltfilkryptering og full diskkryptering, kan bygges inn i AOL Instant Messenger (AIM). I tillegg integreres PGP 9.0 med produkter som Outlook, Microsoft Entourage, Lotus Notes, Qualcomm Eudora, Mozilla Thunderbird og Apple Mail.

PGP bruker et offentlig nøkkelkrypteringssystem som genererer et par krypteringsnøkler - en offentlig nøkkel og en privat nøkkel. De to nøklene er matematisk relatert på en slik måte at data kryptert med den offentlige nøkkelen kun kan dekrypteres med den private nøkkelen. PGP-brukeren genererer en offentlig nøkkel / privat nøkkelpar og publiserer deretter den offentlige nøkkelen i den offentlige nøkkelkatalogen eller på et nettsted. Den hemmelige nøkkelen publiseres selvfølgelig ikke noe sted og holdes hemmelig; den brukes kun av eieren. Ved dekryptering av data ved hjelp av en privat nøkkel kreves et passord, men ved kryptering av data ved hjelp av en offentlig nøkkel oppgis ikke dette fordi alle kan bruke de offentlige nøklene.

For enkel bruk av PGP-systemet har utviklerne implementert funksjonen med automatisk polling av offentlige nøkkelkataloger. Denne funksjonen gjør det mulig, ved å skrive inn e-postadressen til en bruker i søkefeltet, å finne hans offentlige nøkkel. PGP gir muligheten til automatisk å lese offentlige nøkler som kan lagres lokalt på systemet ditt for enkel tilgang i en spesiell filbasert "nøkkelring". Ved å polle katalogen over offentlige nøkler, lar PGP deg alltid beholde de nyeste versjonene av dem i en "haug". Hvis en bruker endrer sin offentlige nøkkel, kan du få tilgang til den oppdaterte nøkkelen når du trenger den.

For å gi mer pålitelige garantier for autentisiteten til offentlige nøkler, kan du bruke digitale signaturer med nøklene til andre brukere. Signaturen til nøkkelen av en annen bruker fungerer som ytterligere bekreftelse på at nøkkelen virkelig tilhører personen som hevder å være dens eier. For å validere en nøkkel ved hjelp av en digital signatur, utfører PGP en matematisk operasjon og legger det unike resultatet til nøkkelen. Signaturen kan deretter verifiseres ved å sammenligne den med signaturnøkkelen som ble brukt til å lage signaturen. Denne prosessen ligner på prosessen der en person bekrefter identiteten til en annen.

PGP-systemet stoler på av mange fordi det lenge har etablert et bransjerykte som en pålitelig teknologi for å beskytte informasjon. Men uansett, hvis du bestemmer deg for å bruke PGP eller en annen metode for å kryptere data ved hjelp av offentlige nøkler, husk at mottakerne av filene dine også må ha et kompatibelt krypteringssystem. En av fordelene med PGP ved bruk av e-post som en dataoverføringskanal er at den støtter sin egen krypteringsmodell, samt X.509 og S/MIME-teknologier, som jeg skal diskutere videre.

I tillegg bør et poeng til. Uansett om du planlegger å bruke PGP, WinZip eller et annet krypteringssystem, hvis du ønsker å kryptere innholdet i meldingen i tillegg til å kryptere de vedlagte filene, må du skrive meldingen til en egen fil og kryptere den også. Om ønskelig kan denne filen med meldingen legges i arkivet sammen med andre filer eller legges ved som en vedleggsfil.

PKI

Public Key Infrastructure (PKI) er unik, men den fungerer litt som PGP. PKI forutsetter bruk av et par nøkler - offentlige og hemmelige. Avsendere bruker mottakerens offentlige nøkkel for å kryptere data sendt til mottakeren; etter at dataene er levert til mottakeren, dekrypterer han dem ved hjelp av sin private nøkkel.

Figur 2: Vise innholdet i et sertifikat

En vesentlig forskjell er at i PKI er den offentlige nøkkelen vanligvis lagret i et dataformat kjent som et sertifikat. Sertifikater kan inneholde mye mer informasjon enn vanlige nøkler. For eksempel inneholder sertifikater vanligvis en utløpsdato, slik at vi vet når sertifikatet og tilhørende nøkkel ikke lenger vil være gyldige. I tillegg kan sertifikatet inneholde navn, adresse, telefonnummer til nøkkelinnehaveren og andre data. Figur 2 viser innholdet i sertifikatet slik det vises i Microsoft Internet Explorer (IE) eller Outlook. Til en viss grad avhenger innholdet i sertifikatet av hva slags data eieren ønsker å plassere i det.

I likhet med PGP, tillater PKI dannelsen av "kjeder av tillit" der sertifikater kan signeres med sertifikater fra andre brukere. I tillegg har sertifiseringsinstanser (CAer) dukket opp. De er pålitelige uavhengige organisasjoner som ikke bare utsteder sine egne sertifikater, men også signerer andre sertifikater for å sikre deres autentisitet. Som med PGP og dens tilknyttede nøkkelservere, kan sertifikater publiseres til offentlige eller private sertifikatservere eller LDAP-servere, sendes via e-post og til og med hostes på nettsider eller på en filserver.

For å gi automatisk sertifikatautentisering, utstyrer utviklere av e-postklienter og nettlesere vanligvis programmene sine med midler for å kommunisere med CA-servere. I løpet av denne prosessen vil du også kunne få informasjon om tilbakekall av sertifikatet av en eller annen grunn og følgelig konkludere med at dette sertifikatet ikke lenger kan stole på. Noen ganger må du selvfølgelig betale for tjenestene til sertifiseringsmyndighetene for levering og sertifisering av sertifikater; prisene kan variere avhengig av den valgte sertifiseringsmyndigheten. Noen organisasjoner gir kundene gratis personlige sertifikater via e-post, mens andre krever betydelige belønninger for dette.

PKI er basert på X.509-spesifikasjonen (avledet fra LDAP X-spesifikasjonen). Derfor kan sertifikater utstedt av en enkelt myndighet (inkludert sertifikater som du genererer for deg selv) vanligvis brukes på en rekke plattformer. Du trenger bare at disse plattformene er X.509-kompatible. Du kan også generere sertifikater selv ved å bruke hvilket som helst av de tilgjengelige verktøyene som OpenSSL.

Hvis organisasjonen din bruker Microsoft Certificate Services, kan du be om et sertifikat gjennom denne tjenesten. I Windows Server 2003- og Windows 2000 Server-miljøer bør denne prosessen være omtrent den samme. Åpne Certificate Server-websiden (vanligvis plassert på http:// servernavn / CertSrv), og velg deretter elementet Be om et sertifikat. På neste side velger du elementet for forespørsel om brukersertifikat og følger instruksjonene til nettveiviseren til prosessen er fullført. Dersom sertifikattjenesten er konfigurert på en slik måte at det kreves autorisasjon fra administrator for å utstede et sertifikat, vil systemet varsle deg om dette med en spesiell melding, og du må vente på administrators avgjørelse. Ellers vil du ende opp med en hyperkobling som lar deg installere sertifikatet.

Noen uavhengige CA-er, som Comodo Groups Thwate og InstantSSL, tilbyr brukere gratis personlige e-postsertifikater; det er en enkel måte å få sertifikater på. I tillegg vil slike sertifikater allerede være signert av den utstedende myndigheten, noe som gjør det lettere å verifisere deres autentisitet.

Når det gjelder å bruke PKI til å sende krypterte data ved hjelp av et e-postprogram, kommer Secure MIME (S / MIME)-spesifikasjonen inn. Outlook, Mozilla Thunderbird og Apple Mail er bare noen få eksempler på e-postprogrammer som aktiverer denne protokollen. For å sende en kryptert e-postmelding til mottakeren (inkludert eller ikke inkludert vedlagte filer), må du ha tilgang til mottakerens offentlige nøkkel.

For å få en annen brukers offentlige nøkkel, kan du se nøkkelinformasjonen på LDAP-serveren (hvis bare nøkkelen er publisert med LDAP). Alternativt kan du be personen sende deg en digitalt signert melding; Vanligvis legger S/MIME-aktiverte e-postklienter ved en kopi av den offentlige nøkkelen når de leverer en signert melding til mottakeren. Eller du kan ganske enkelt be personen du er interessert i om å sende deg en melding med den offentlige nøkkelen knyttet til den. Deretter kan du lagre denne offentlige nøkkelen i nøsom følger med e-postklienten din. Outlook integreres med Windows' innebygde Certificate Store. Hvis du trenger å bruke en offentlig nøkkel, vil den alltid være tilgjengelig.

Avsenderbasert kryptering

Voltage Security har utviklet en ny teknologi – identitetsbasert kryptering (IBE). Generelt ligner den PKI-teknologi, men den har en interessant funksjon. Den hemmelige nøkkelen brukes til å dekryptere meldinger i IBE, men den vanlige offentlige nøkkelen brukes ikke under krypteringsprosessen. IBE bruker avsenderens postadresse som en slik nøkkel. Dermed, når du sender en kryptert melding til mottakeren, oppstår ikke problemet med å skaffe hans offentlige nøkkel. Det er nok å ha denne personens e-postadresse.

IBE-teknologien forutsetter lagring av mottakerens hemmelige nøkkel på nøkkelserveren. Mottakeren bekrefter sine tilgangsrettigheter til nøkkelserveren og mottar en hemmelig nøkkel, som han dekrypterer innholdet i meldingen med. IBE-teknologien kan brukes av brukere av Outlook, Outlook Express, Lotus Notes, Pocket PC og Research in Motion (RIM) BlackBerry. I følge Voltage Security kjører IBE også på alle nettleserbaserte e-postsystemer som kjører praktisk talt alle operativsystemer. Det er sannsynlig at slike allsidige spenningssikkerhetsløsninger er akkurat det du trenger.

Spesielt brukes IBE-teknologi i FrontBridge Technologies' produkter som et middel for å forenkle sikker kryptert e-postkommunikasjon. Som du sikkert allerede vet, ble FrontBridge i juli 2005 kjøpt opp av Microsoft, som planlegger å integrere FrontBridge-løsninger med Exchange; en kombinasjon av disse teknologiene kan snart tilbys forbrukere som en administrert tjeneste. Hvis din organisasjons og dine partneres e-postsystemer er basert på Exchange, hold et øye med utviklingen på dette området.

Alt tatt i betraktning

Det er mange måter å sikkert overføre filer over Internett på, og den desidert enkleste og mest effektive av disse er via e-post. Selvfølgelig kan de som må utveksle et stort antall filer som utgjør store datamengder vurdere å bruke andre metoder.

Du bør nøye vurdere hvor mange filer du vil overføre, hvor store de er, hvor ofte du må overføre disse filene, hvem som skal ha tilgang til dem, og hvordan de vil bli lagret ved mottakspunktet. Ta disse faktorene i betraktning, kan du velge den beste måten å overføre filer på.

Hvis du konkluderer med at e-post er det beste alternativet for deg, husk at mange e-postservere og e-postklienter kan kjøre skript eller regelbaserte handlinger når e-post kommer. Ved å bruke disse funksjonene kan du automatisere bevegelsen av filer både langs ruten på e-postservere og når filer kommer i postkassen.

Mark Joseph Edwards er seniorredaktør for Windows IT Pro og forfatter av den ukentlige sikkerhetsoppdateringen ( http://www.windowsitpro.com/email). [e-postbeskyttet]



Andrey Subbotin Materialet er gjengitt med tillatelse fra forlaget.

For tiden er det en kraftig økning i mengden informasjon (inkludert konfidensiell) som overføres over åpne kommunikasjonskanaler. Gjennom vanlige telefonkanaler gjennomføres samhandling mellom banker, meglerhus og børser, eksterne filialer av organisasjoner, verdipapirer omsettes. Derfor blir problemet med å beskytte den overførte informasjonen mer og mer presserende. Til tross for at spesifikke implementeringer av informasjonssikkerhetssystemer kan avvike betydelig fra hverandre på grunn av forskjellen i prosesser og dataoverføringsalgoritmer, må de alle gi en løsning på et treenig problem:

    konfidensialitet av informasjon (dens tilgjengelighet kun for den den er ment for);

    integriteten til informasjonen (dens pålitelighet og nøyaktighet, samt sikkerheten til dens tilsiktede og utilsiktede forvrengninger);

    informasjonsberedskapen (til enhver tid når behovet oppstår for det).

De viktigste retningslinjene for å løse disse problemene er ikke-kryptografisk og kryptografisk beskyttelse. Ikke-kryptografisk beskyttelse inkluderer organisatoriske og tekniske tiltak for å beskytte anlegg, redusere nivået av farlig stråling og skape kunstig interferens. På grunn av kompleksiteten og volumet til dette emnet, vil ikke-kryptografisk beskyttelse ikke bli vurdert i denne artikkelen.

Kryptografisk beskyttelse er i de fleste tilfeller mer effektivt og billigere. I dette tilfellet er konfidensialiteten til informasjonen sikret ved kryptering av overførte dokumenter eller all trafikk av arbeid.

Det første alternativet er enklere å implementere og kan brukes til å jobbe med nesten alle e-postoverføringssystem. De mest brukte krypteringsalgoritmene er DES, RSA, GOST 28147-89, Vesta-2.

Det andre alternativet kan bare brukes i spesialdesignede systemer, og i dette tilfellet kreves en høyhastighetsalgoritme, siden det er nødvendig å behandle informasjonsstrømmer i sanntid. Dette alternativet kan betraktes som sikrere enn det første, siden ikke bare de overførte dataene er kryptert, men også den medfølgende informasjonen, som vanligvis inkluderer datatyper, sender- og mottakeradresser, transittveier og mye mer. Denne tilnærmingen kompliserer betydelig oppgaven med å introdusere falsk informasjon i systemet, samt duplisere tidligere fanget ekte informasjon.

Integriteten til informasjonen som overføres gjennom åpne kommunikasjonskanaler sikres ved bruk av en spesiell elektronisk signatur, som gjør det mulig å fastslå informasjonens forfatterskap og autentisitet. Elektronisk signatur er i dag mye brukt for å bekrefte den juridiske betydningen av elektroniske dokumenter i slike informasjonsutvekslingssystemer som bank - bank, bank - filial, bank - klient, børs - megler osv. Blant de vanligste algoritmene for elektronisk signatur er følgende f.eks. RSA, PGP, ElGamal.

Informasjonsberedskapen i de fleste tilfeller sikres ved organisatoriske og tekniske tiltak og installasjon av spesielt feiltolerant utstyr. Valget av en eller annen kryptografisk transformasjonsalgoritme er vanligvis beheftet med store vanskeligheter. Her er noen typiske eksempler.

Anta at utvikleren av beskyttelsessystemet hevder å ha implementert kravene til GOST 28147-89 i den. Denne GOST er publisert, men ikke i sin helhet. Noen spesielle kryptografiske erstatninger, som dens kryptografiske styrke avhenger vesentlig av, har ikke blitt publisert. Dermed kan man være sikker på riktigheten av GOST-implementeringen bare hvis det er et FAPSI-sertifikat, som de fleste utviklere ikke har.

Sikkerhetsutvikleren rapporterer at de har implementert RSA-algoritmen. Han er imidlertid taus om at implementeringen må være lisensiert av RSA Data Security Inc. (US patent nr. 4.405.829). Videre er eksport fra USA av RSA-implementeringer med en nøkkellengde på mer enn 40 biter forbudt (den kryptografiske styrken til en slik nøkkel er estimert av eksperter i løpet av noen få dagers drift av en vanlig datamaskin med en Pentium-prosessor).

Utvikleren av sikkerhetssystemet informerer om at det implementerer PGP-algoritmen, som er mye brukt i vårt land takket være kildekoden, som ble distribuert gratis frem til 1995 gjennom US BBS. Det er to problemer her. Den første er at den elektroniske signaturen er laget på grunnlag av RSA-algoritmen og, når det gjelder opphavsrettslig beskyttelse, også må være lisensiert av RSA Data Security Inc. Den andre er at de distribuerte programmene er ufølsomme for forstyrrelser i arbeidet deres, og ved å bruke et spesielt kryptovirus kan du enkelt få tak i en hemmelig nøkkel for å generere en elektronisk signatur.

Avslutningsvis vil jeg med beklagelse bemerke at det i vårt land praktisk talt ikke er noen regulatorisk og metodisk base, ved hjelp av hvilken det ville være mulig å rimelig sammenligne de foreslåtte iog velge de mest optimale løsningene.



© Copyright 2017, https://qzoreteam.ru