NO327765B1 - Fremgangsmate og et arrangement relatert til sikkerhetsmekanismer for meldingsbaserte elektroniske transaksjoner - Google Patents

Abstract

Et arrangement for deklarasjon av sikkerhetsnivå av transportbaner/ruter i et eller flere datanettverk hvor arrangementet i det minste omfatter: en enhet (3) konfigurert til å undersøke noder i nevnte minst ene datanettverk med henblikk på nevnte noders sikkerhetsnivå og/eller nevnte noders innehadde sertifikater, i det minste en database hvor nevnte database omfatter informasjon om styrke av sertifikater og utstedere av sertifikater, i det minste en mekanisme konfigurert til å fremhente informasjon fra domenenavneservere (2), og et grensesnitt konfigurert til å motta anmodning om deklarasjon fra en eller flere sendere (1).Foreliggende oppfinnelse offentliggjør også en korresponderende fremgangsmåte for deklarasjon av sikkerhetsnivå av transportbaner/ruter i et eller flere datanettverk.

Description

SIKKER UTVEKSLING AV MELDINGER

Teknisk område

Foreliggende oppfinnelse vedrører en fremgangsmåte og et arrangement relatert til sikkerhetsmekanismer for meldingsbaserte elektroniske transaksjoner; særlig bruk av protokollen TLS - Transport Layer Security for å etablere en dynamisk sikker rute til i prinsippet enhver uavhengig part. I tillegg vedrører oppfinnelsen bestemmelse av kvalitetsnivåer av en slik rute, basert på vurderinger av TLS-sertifikatet, IP-adressen, domenenavnet, servernavnet osv som befinner seg på mottakerstedet.

Bakgrunnsteknikk

Kryptering (bevis på konfidensialitet) er avgjørende for mange meldingsapplikasjoner og tjenester i den elektroniske verden. I dag oppnås dette hovedsakelig ved faste og lukkede brukergrupper hvor den samme kryptografiske programvare og/eller maskinvare må utplasseres blant definerte kommunikasjonsparter før sikker melding kan skje.

Dette er hovedhindringen for brukere som har behov for øyeblikkelig tilgjengelig sikker kommunikasjon mot enhver tilfeldig og uavhengig part, og derfor må basere seg på en mekanisme som dynamisk deklarerer sikre ruter mellom senderen og mottakerne før meldinger blir sendt.

Hvor meldingstjenester på sendestedet har evnen til å ta fordel av TLS-forbindelser mot mottakende meldingstjenester, vil de betjene sendere uten en definert beskyttelseskvalitet, siden de bare bruker det som for tiden er tilgjengelig på mottakerstedet. Hvis TLS-forbindelsen ikke er mulig å etablere, sendes meldinger standard i klartekst uten enhver mekanisme for alternativ beskyttelse, slik som å vente med meldingen, eller advare senderen for sending eller tilby en sikker omruting osv.

Fundamentalt er problemet adressert av foreliggende oppfinnelse mangel av informasjon med henblikk på nivået tilbakemelding om sikkerhet/konfidensialitet gitt til enhver sender av elektroniske meldinger. Selv om en mottakende part synes å tilby en sikker tjeneste gjennom dens meldingmottakende server, kan ikke senderen nødvendigvis stole på de mellomliggende noder/servere. En melding fra en sender kan være komponert av flere pakker av data, hvor forskjellige pakker rutes gjennom nettverkene på forskjellige baner; derfor kan sikkerhetsnivået mellom senderen og den mottakende part variere selv innen en melding. Du kan være "heldig" en dag, mens du den neste dagen vil oppleve at meldingen din overføres via usikrede noder på grunn av overbelastede nettverk. Det følger av seg selv at sendere med behov for overføring av sensitive data ikke kan leve med disse usikkerheter.

Det er ikke bare behov for tilbakemelding; det er videre mangel på kontroll for senderen. En mottakende part kan som indikert ovenfor være "sikker"; imidlertid kan meldinger ta en "usikker" rite gjennom nettverket, på grunn av overbelastede nettverk eller andre årsaker, dette gir den uinformerte sender trygghet for at meldingsoverføringen var sikker, men den ikke var det. det burde vært mekanismer som tillot sender å holde tilbake meldinger i tilfelle hvor en sikker rute ikke kan garanteres. Videre skal ikke pakker av data med en "reservert rute" rutes via usikre noder selv om det er overbelastning i nettverket, i slike situasjoner er det bedre å legge pakker i kø mens de venter på en sikker bane. Det er derfor behov for nettverksadministrasjon som tillater ruting av datapakker ifølge et påkrevet sikkerhetsnivå.

Hovedproblemene er:

Sendere bak TLS-baserte meldingstjenester må vite hvem meldingsinnholdet (for eksempel email) overføres sikkert før meldingstjenesten brukes.

Sendere betjenes ikke av meldingstjenester for å utrede beskyttelseskvaliteten som tilbys på det mottakende stedet.

Ingen krav av senderen til kvaliteten av TLS-forbindelsen tas i betraktning.

Sendere må manuelt eller på andre måter undersøke hvilke typer forutsetninger de mottakende parter har før sensitivt innhold overføres.

Mangelen av brukervennlighet fører til enten lekkasje av sensitiv informasjon til åpne nettverk ved uhell eller hindrer brukerne å effektivt ta fordelene av å bruke moderne meldingsteknologi for tjenester som har behov for konfidensialitet.

Et eksempel på en velkjent meldingsutvekslingsklient er Microsoft Exchange Server 2007 som fullt ut åpenbarer problemer relatert til sikker meldingsutveksling mellom parter. Et scenario kan være som følger: • Hvis senderen har en email distribusjonsliste over mottakere som skal brukes med den hensikt å distribuere konfidensielt innhold, sender Microsoft Exchange Server 2007 email over TLS der hvor dette er tilgjengelig og i klartekst overalt ellers. • Hvis TLS-forbindelser brukes av Microsoft Exchange Server 2007 på vegne av brukere, tas ingen kvalitetskarakteristikker definert av senderen i betraktning. For eksempel at senderen krever et sertifikat av et bestemt kvalitetsnivå fra en kommersielt betrodd tredje part, som et alternativ til, som diktat, å akseptere et selvsignert sertifikat utstedt av den mottakende part, som er standardmetoden implementert i Microsoft Exchange Server 2007.

Diskusjonen ovenfor indikerer klart behovet for en forbedret administrasjon av datapakketransport med sikkerhetskrav. Videre er det behov for å tilby sendere av sensitive data en løsning med deklarerte sikre ruter fra sender til mottakere.

Beskrivelse av oppfinnelsen

Hensikten med foreliggende oppfinnelse er å overvinne problemene beskrevet ovenfor ved å introdusere en ny fremgangsmåte og arrangement hvor en sender får en deklarasjon som indikerer et sikkerhetsnivå for en eller flere ruter i et transportnettverk. Foreliggende oppfinnelse presenterer derfor en fremgangsmåte og et arrangement relatert til sikkerhetsmekanismer for meldingsbaserte elektroniske transaksjoner; spesifikt for bruk av protokollen TLS - Transport Layer Security for å en dynamisk sikker rute til i prinsippet enhver uavhengig part. I tillegg vedrører oppfinnelsen bestemmelse av kvalitetsnivået av en slik rute, basert på vurderinger av TLS-sertifikatet, IP-adressen, domenenavnet, servernavnet osv. lokalisert på det mottakende sted.

Andre fordeler og egenskaper som særpreger oppfinnelsen vil fremgå av de vedføyde krav.

Kortfattet beskrivelse av figurene i tegningene

For en bedre forståelse av oppfinnelsen vises det til den etterfølgende beskrivelse og de vedføyde tegninger hvor:

Figur 1 er et enkelt diagram som viser TLS-deklarasjon.

Figur 2 er et blokkdiagram av en anmodning og responsmodell ifølge en utførelse av foreliggende oppfinnelse.

Modus(er) for utførelse av oppfinnelsen

For å lette forståelsen vil foreliggende oppfinnelse nå bli beskrevet med henvisning til figurene. Figurene er bare inkludert for illustrasjonsformål og er ikke ment å begrense beskyttelsesomfanget, idet en fagkyndig person vil forstå at det er andre fordelaktige løsninger som åpenbart av de vedføyde krav.

Ifølge foreliggende oppfinnelse inkluderer arrangementet i det minste en enhet (3) konfigurert til å undersøke noder i et datanettverk med henblikk på nevnte noders sikkerhetsnivå/nevnte noders sertifikater. Det vil si hvilket sertifikat, om noe, som innehas av den minst ene undersøkte. Fortrinnsvis omfatter enheten også i det minste en database hvor nevnte database inkluderer informasjon om styrken av sertifikater og utstedere av sertifikater. Enheten omfatter videre en mekanisme konfigurert til å fremhente informasjon fra domenenavneservere (2). Den fremhentede informasjon fra DNS (2) servere kan blant annet være informasjon relatert til mottakende servere eller mellomliggende noder og deres typer av sertifikater osv. Enheten er videre konfigurert med et grensesnitt mot en eller flere sendere (1). Senderne (1) er brukere av tjenesten levert av enheten (3), som krever et deklarert nivå for sikkerhet/konfidensialitet på deres meldingsutveksling. For å lette lesbarheten blir nevnte enhet (3) heretter kalt en TLS-kravler, som på ingen måte er ment å begrense TLS-kravleren (3) til å være en tradisjonell web eller databasekravler.

Arrangementet og fremgangsmåten ifølge foreliggende oppfinnelse gir ikke bare informasjon vedrørende sikkerhetsnivået for overføring av data i datanettverk mellom sendere (1) og mottakere (4), det sikrer også et valgt nivå av sikkerhet for senderne forutsatt at det valgte nivå er tilgjengelig. Hvis det valgte nivå ikke er tilgjengelig på grunn av overbelastning, vil senderen (1) bli informert og gitt valget av å abortere dataoverføringen. Han vil ikke, slik det er vanlig, oppleve at dataoverføringen stoppes, rerutes og formidles via noder som ikke oppfyller kriteriene for sikkerhet/konfidensialitet. For senderen ses arrangementet og metoden som en tjeneste for kvalitetssikring av arrangementet og fremgangsmåten som etablerer en tunell for sikker tunellering av data mellom endepunktene (1,4).

I et scenario har sendere bak senderneldingstjeneste 2 - SMS2 (11) behov for å overføre sensitivt innhold til mottakere bak mottakende meldingstjenester 1 - RMS1 (41) og mottakende meldingstjenester 2 - RMS2 (42).

SMS2 (11) ønsker å deklarere om det eksisterer en sikker TLS-rute til både RMS1 (41) og RMS2 (42) med et akseptabelt kvalitetsnivå, eller ikke. SMS2 (11) har ingen kjennskap til kvalitetsnivået på de mottakende steder, siden de er tilfeldige og uavhengige parter. For å bestemme anvendbarheten av den sikre meldingstjeneste, om noen, spør SMS2 (11) TLS-kravleren om en status og kvalitetsvurderingstjeneste, kalt en deklarasjonsanmodning (33, 34, 35), og etter prosessering i den oppfunnede kravlermekanisme, får SMS2 (11) tilbake et ja- eller nei-svar, sammen med kvalitetsindikatorer, valgfritt angitt av senderen i deklareringsanmodningen (33, 34, 35).

TLS-kravleren er en server som opererer i to forskjellige modi; søkemodus eller forhåndsdefinert. I søkemodus finner TLS-kravleren tilgjengelige mottakere for en gitt meldingstransport (for eksempel mottakende mailservere). I forhåndsdefinert modus sjekker TLS-kravlerennøyaktig serveradressen eller domenenavnet gitt som en parameter (for eksempel xx@min- bedrift. com). Uavhengig av operasjonsmodus er resultatet fra TLS-kravleren en kvalitetsangivelse av sikkerhetsinnstillingene av mottakeren (dvs. mottakende server). Kvalitetsangivelsen rapportert tilbake til senderen kan være enkel (for eksempel ja eller nei for en gitt sikkerhetsterskel) eller kompleks (for eksempel sikkerhetsparametre slik som kryptoalgoritmer, nøkkellengder, sertifikater og trafikkdata ved test, responstid, DNS-endringer osv.). TLS-kravleren bruker en intern database for å lagre all (dvs. kompleks) mottakerinformasjon. For å være i stand til å gi en enkel respons til senderen, må TLS-kravleren kjenne sikkerhetsterskelen av senderen. Terskelen kan være forhåndsdefinert som en konfigurasjon i TLS-kravleren eller terskelen kan sendes av senderen som en konfigurasjonsanmodning. En sender kan ha flere terskler og hver terskel for en gitt sender identifiseres av et nummer i den enkle responsanmodningen til TLS-kravleren.

En modus for utførelse av oppfinnelsen

En modus for å utføre oppfinnelsen vil nå bli forklart med støtte fra figur 2.

1. Senderen (1) sender en deklareringsanmodning (33, 34, 35)

a. En deklareringsanmodning (33, 34, 35) er en elektronisk sendt meldingsanmodning fira senderen (1) som spør:

• Om noen TLS-forbindelse er tilgjengelig for en gitt mottaker (4), spesifisert av mottakerens adresse, for eksempel en SMTP, http, NNTP eller annen adresse som bruker TLS for sikkerhet. • Deklareringsanmodningen kan inkludere sikkerhetskrav som parametre til anmodningen. • Deklareringsanmodningen (33, 34, 35) kan leveres med enhver egnet, åpen standardprotokoll slik som http, SMTP, LD AP, SAML eller proprietære

protokoller.

2. TLS-kravleren (3) verifiserer meldingsserverens adresse a. En verifisering av mottakerens (4) meldingstjeneste er en elektronisk sendt melding fra TLS-kravleren (3) til en domenenavneserver - DNS (2) som holder adresseringsdetaljene til mottakerens (4) meldingstjeneste og spør om:

• Servernavnet til maskinen som kjører meldingstjenesten (4).

• IP-adressen som er assosiert med den aktuelle maskin

b. Når det er påkrevet blir data (32) hentet fram fra DNSen (2), idet dataene lagres i

en TLS-kravler database (3).

c. Hvis IP-adressen eller det relaterte maskinnavnet allerede eksisterer i databasen, sjekker en sammenligningsoperasjon om denne databaseposten er inkonsistent med den sist oppnådde informasjon fra DNSen. Hvis det er endringer vil TLS-kravleren (3) frambringe et elektronisk sendt meldingsvarsel som vil legges inn i

deklareringsresponsen (5), beskrevet nedenfor.

3. TLS-kravleren (3) verifiserer kvaliteten av TLS-forbindelsen a. En TLS utfordringsrespons (challenge-response) som definert i TLS-standarden blir initiert av TLS-kravleren (3) og sendt til IP-adressen til meldingsserveren (4) på det mottakende sted, for tiden framhentet fra DNSen, som vil resultere i

enten en fullt prosessert TLS-forbindelse eller ikke.

b. Hvis ingen TLS-forbindelse ble prosessert eller var tilgjengelig, frembringes det en elektronisk sendt melding for å indikere tilstanden i deklareringsresponsen

(5) , beskrevet nedenfor.

c. Hvis resultatet er en vellykket TLS-forbindelse, henter TLS-kravleren fram mottakerstedets (4) sertifikat. TLS-kravleren (3) kan validere sertifikatet og vurdere kvaliteten basert på senderens tillit til utstederen (for eksempel om det er selvsignert eller ikke), og frembringe en elektronisk melding som relaterer til de valgfrie kvalitetsparametre angitt i senderens deklareringsanmodning (33, 34, 35).

4. TLS-kravler respons (5)

a. En TLS-kravler respons (5) er en elektronisk melding sendt til senderens meldingstjeneste (1). Responsen settes sammen som et resultat av prosesser

beskrevet ovenfor og leveres ved bruk av enhver egnet åpen protokoll slik som LD AP, SAML, http, SMTP eller proprietære protokoller.

b. En obligatorisk parameter i responsen er om en TLS-forbindelse for tiden er

tilgjengelig eller ikke mot mottakerens meldingstjeneste (4).

c. Flere valgfri parametre i responsen kan leveres, basert på to klasser:

i. Valgfri parametre angitt av senderen (1) i anmodningen, slik som et krav om et validert sertifikat utstedt av en gitt kommersiell sertifikatmyndighet. ii. Valgfri parametre generert av TLS.-kravleren (3), slik som et sikkerhetsvarsel, for eksempel frembrakt som et resultat av mistenkelig eller sannsynlig mann-i-midten angrep.

Veiledning til henvisningstall benyttet i figurene

1 Sendere

10 Sendemeldingstj eneste 1, sikkerhetspolicy A

11 Sendemeldingstj eneste 2, sikkerhetspolicy B

12 Sendemeldingstj eneste 3, sikkerhetspolicy C

2 Domenenavnserver (DNS)

21 Mottakende server 1

22 Mottakende server 2

23 Mottakende server 3

3 TLS-kravler ifølge foreliggende oppfinnelse

31 TLS-kravler status og kvalitetsvurdering

32 Fremhenting av DNS info om mottakende server (21,22, 23) 33, 34, 35 Deklarasjonsanmodning

36, 37, 38 TLS-sjekk

4 Mottakere

41 Mottakende meldingstjeneste 1

42 Mottakende meldingstjeneste 2

43 Mottakende meldingstjeneste 3

5 Respons, deklarert/ikke deklarert TLS-forbindelse

Claims (8)

1. Arrangement for deklarasjon av sikkerhetsnivå av transportbaner/ruter i et eller flere datanettverk karakterisert ved at arrangementet i det minste omfatter: en enhet (3) konfigurert til å undersøke noder i nevnte minst ene datanettverk med henblikk på nevnte noders sikkerhetsnivå og/eller nevnte noders innehadde sertifikater, i det minste en database hvor nevnte database omfatter informasjon om styrke av sertifikater og utstedere av sertifikater, i det minste en mekanisme konfigurert til å fremhente informasjon fra domenenavneservere (2), og et grensesnitt konfigurert til å motta anmodning om deklarasjon fra en eller flere sendere (1).

2. Fremgangsmåte for deklarasjon av sikkerhetsnivå av transportbaner/ruter i et eller flere datanettverk, hvor nettverkene omfatter i det minste en eller flere sendere (1), i det minste en eller flere mottakere (4), i det minste en eller flere mellomliggende noder karakterisert ved at fremgangsmåten i det minste omfatter trinnene: den minst ene eller flere sendere (1) sender en deklarasjonsanmodning til en enhet (3), enheten verifiserer den minst ene mottakerens (4) meldingstjenesteadresse, ved: undersøkelse av en domenenavneserver (2) som har tilgang til adresseringsdetaljer for den minst ene mottakers (4) meldingstjenesteadresse med henblikk på servernavn til maskinene som kjører i det minste en meldingstjeneste (4) og adressen assosiert med denne, eller undersøkelse av en database eller lagringsmiddel tilgjengelig for enheten (3) hvor databasen eller lagringsmiddel et har tilgang til adresseringsdetaljene til den minst ene mottakers (4) meldingstjenesteadresse med henblikk på servernavn til maskiner som kjører den minst ene meldingstjeneste (4) og adressen assosiert med den, og enheten (3) verifiserer sikkerhetsnivået eller nivået av konfidensialitet av den ene eller flere forbindelser anmodet av den minst ene sender, og enheten sender en respons (5) til den ene eller flere sendere (1).

3. Fremgangsmåte ifølge krav 2, karakterisert ved at deklarasjonsanmodningen i trinn a videre omfatter å spørre vedrørende: om et anmodet sikkerhetsnivå er tilgjengelig for den ene eller flere mottakere (4), om den gjeldende sikre forbindelse tilveiebringer sikkerhetskrav, valgfritt angitt av senderen (1).

4. Fremgangsmåte ifølge krav 2, karakterisert ved at trinn b videre omfatter trinnene å lagre data fremhentet (32) fra domenenavneserveren (2) i en database som er tilgjengelig for enheten (3).

5. Fremgangsmåte ifølge krav 4, karakterisert ved at om adressen eller relatert maskinnavn allerede eksisterer i databasen som er tilgjengelig for enheten (3) å sammenligne om nevnte databasepost er konsistent med den siste informasjonen tilveiebrakt fra domenenavneserveren (2), hvis det eksisterer inkonsistens å frembringe et varselsignal ved enheten (3).

6. Fremgangsmåte ifølge krav 2, karakterisert ved at trinn c videre omfatter trinnene: frembringe (3) en utfordring for å avdekke sikkerhetsnivået av en utfordrende part og å forberede forbindelse til den utfordrede part hvis sikkerhetsnivået er i samsvar med utfordringen, formidle utfordringen til adressen til meldingsserveren (4), og om anmodet sikkerhetsnivå ikke er tilgjengelig å frembringe en melding som indikerer at det anmodede sikkerhetsnivå er utilgjengelig ved den ene eller flere mottakere (4), eller om anmodet sikkerhetsnivå er tilgjengelig henter enheten (3) frem fra den ene eller flere mottakere (4) et eller flere sertifikater og frembringer en melding som indikerer at det anmodede sikkerhetsnivå var tilgjengelig ved den ene eller flere mottakere (4).

7. Fremgangsmåte ifølge krav 6, karakterisert ved at om det anmodede sikkerhetsnivå var tilgjengelig validerer enheten (3) sertifikatene og vurderer kvaliteten basert b på den ene eller flere senderes (1) tillit til utstederen.

8. Fremgangsmåte ifølge et av kravene 6 eller 7, karakterisert ved at meldingen frembrakt av enheten (3) formidles til den ene eller flere sendere (1).