NO326342B1 - Metode og anordning for automatisk tjenestelevering, lisensering og konfigurering av klientprogramvare - Google Patents

Description

Kjent teknikk.

En publikasjon utgitt av Microsoft Corporation, i juni 2004, med oppdatert utgave 2005, som bærer tittelen "IEEE 802.11 Wireless LAN Security with Microsoft Windows XP" beskriver sikkerhet i trådløse nettverk med hensyn til forskjellige teknikker. Der angis at selv om trådløse ELAN-nett gir bevegelsesfrihet, kan de også kreve at brukeren tar hensyn til sikkerhetsspørsmål som ikke er så fremtredende på et privat kabelsystem for entrådkoplet ELAN-teknikk slik som internert Hoveo^ikkerhetsspørernålene er autentiseringen av trådløse klienter og krypteringen og dataintegriteten til rammer på trådløse ELAN. Særlig beskrives på sidene 1-13 en såkalt "EAP-TLS authentication". Under punkt 9 finner man overskriften "EAP success from the radio server", hvor det gis en beskrivelse av hvordan nøklingen fra server mot aksesspunktet foregår.

I publikasjonen med tittelen "Deploying Wi-Fi Protected Access (WPA™) and WPA2™ in the Enterprise", utgitt av Wi-Fi Alliance, i mars 2005, beskrives implementering av sikkerhetsløsningen WPA og WPA2 irm i eksisterende trådløse nettverk. Særlig beskrives på sidene 7-9 nøklingen med såkalte symmetriske siffernøkler av brukerens identifisering, lagring av informasjon slik som brukeridentitet, som i denne publikasjonen omtales som "akkreditiver" (tilsvarer det engelske begrepet "credentials").

Introduksjon

Den foreliggende oppfinnelsen (se figur 1 for en oversikt) muliggjør en bruker-spesifikk tjeneste, som en tjeneste bygget rundt en mobil terminal (100) med en klientprogramvare (som f.eks. Mobil IP), til å virke spesifikt med en tilhørende server-infrastruktur (101,102) ved hjelp av en leveransetjener (103). Det overordnede designmålet er å minimalisere de nødvendige tilpasninger på klienten og gi så mye som mulig av kontrollen til serversiden. Tjenesten er utformet for å virke med et vilkårlig klientoperativsystem.

En grunnleggende forutsetning er at klienten som standard er bundet til den bruker-spesifikke tjenesten ved installasjon av programvaren. Det er et konfigurabelt antall dager med kostnadsfri prøvetid for denne tjenesten etter initiell aktivering. Etter at prøvetiden er utløpt, dirigeres brukeren til en betalingstjeneste (104) der hun eller han gis muligheten til å fortsette tjenesten ved å akseptere en avgift, betalt med kredittkort eller ved andre midler. Ved å betale får brukeren en full programvarelisens. Utstyrt méd en full programvarelisens kan brukeren benytte klienten med en brukerspesifikk tj enesteleverandør.

Systemet er administrert via et standardwebgrensesnitt som er tilgjengelig for en personlig administrasjonsdatamaskin (105).

Merk at tjenestekonseptet kan betraktes i en generell sammenheng. Klienten kan motta lisenser fra en aktør og tjenesteleveranse fra en annen aktør.

Lisens policy

Konstruksjonen av den bruker-spesifikke tjenesten avhenger av lisensierings-policy for tjenesten. Policy som velges er basert på de følgende tre fundamenter: 1. En klientprogramvarelisens er alltid assosiert med et tjenesteabonnement. I prøveperioden er det en 1:1 forbindelse, dvs. at klienten kan bare brukes med den bruker-spesifikke tjenesten. Dersom abonnementet er fornyet ved betaling, og en full programvarelisens er godkjent, er det en 1 :n forbindelse. Det betyr at klienten kan brukes med en vilkårlig tjenesteleverandør. Imidlertid er klienten fortsatt forbundet med den bruker-spesifikke tjenesten når det gjelder lisenshåndtering. Dersom brukeren reinstallerer klientprogramvaren, på den samme terminalen eller en annen terminal, vil den lokalt lagrede lisensinformasjonen som standard være en ukjent lisens. Brukeren må i dette tilfelle re-aktivere en gang med den bruker-spesfikke tjenesten for å låse opp klienten og gjenetablere den originale konfigurasjon og få tilbake sine fulle lisensrettigheter. 2. Et tjenesteabonnement, og derved en programlisens, er registrert med en unik terminal men kan flyttes mellom terminaler. Brukeren kan imidlertid bruke lisensen fra bare en terminal ad gangen. Det bruker-spesifikke konfigurasjonssystemet vil automatisk detektere en overføring av lisens og da endre den registrerte terminal-assosiasjonen tilsvarende. Installasjonen av programvare på den originale terminalen vil imidlertid fortsatt virke i henhold til fulle lisensrettigheter. Av denne grunn bør en en-av-gangen restriksjon bli lagt inn som en juridisk klausul i lisensteksten. 3. Et tjenesteabonnement, og derved en programlisens, kan aktiveres for prøveperiode bare en gang for en bestemt terminal. Brukeren kan re-aktivere fra same terminal med det same kontonavnet for å gjenskape taptjenestekonfigurasjonsdata. Ethvert forsøk på å registrere flere ganger fra same terminal med et annet kontonavn vil blokkeres av det bruker-spesifikke tjenestesystemet. Deteksjon av misbruk kan gjøres på tjenerseiden ved å overvåke antall lisensflyttinger, som igjen kan bli blokkert av tjeneren.

Foreliggende oppfinnelse tilveiebringer et klient/tjener-arrangement for sikker og automatisk konfigurering av en trådløs terminal med en klient for et lisensnøkkelavhengig, brukerspesifikt tjenesteabonnement tilveiebrakt av en tjenesteleverandør gjennom fremstilling og bruk av krypteringsnøkkelen og brukerspesifikk informasjon i en tjener, og hvor tjeneren er anordnet i en vertsdatamaskin tilsluttet testleverandøren, kjennetegnet ved de trekk som fremgår av det vedfølgende selvstendige patentkrav 1.

Ytterligere fordelaktige trekk ved foreliggende oppfinnelse fremgår av de vedfølgende uselvstendige patentkravene 2 til og med 15.

Kort beskrivelse av oppfinnelsen.

Klient/tjener arrangement for sikker og automatisk konfigurering av en trådløs terminal for et bruker-spesifikt tjenesteabonnement gjennom fremstilling og bruk av krypteringsnøkler og bruker-spesifikk informasjon, hvor klienten er anordnet i terminalen (100) og tjeneren er anordnet i en vertsdatamaskin (103) tilsluttet en tjenesteleverandør, som kjennetegnes ved at klienten (100) er anordnet til å overføre fra terminalen til tjeneren (103) en terminal-spesifikk identitet (320) og en bruker-identitet

(321) innmatet av brukeren, at tjeneren (103) er anordnet til å generere lisens nøkkel (324 licinfo), klient-krypteringsnøkkel (322 clikey), bruker-spesifikk klientnøkkel (326 mipkey) og generell krypteringsnøkkel (323 enckey) og generell krypteringsnøkkel (323 enckey) benyttes til å kryptere data som oversendes fra tjeneren til terminalen, at tjeneren (103) er anordnet til at den generelle krypteringsnøkkelen (323 enckey) krypteres med en kryptografisk nøkkel (327), at tjeneren (103) er anordnet til å lagre bruker-identitet (321), terminal-spesifikk identitet (320) og bruker-spesifikk klientnøkkel (326) i en database, at tjeneren (103) er anordnet til å returnere til klienten

(100) lisens nøkkel (324 licinfo), klient-krypteringsnøkkel (322 clikey), bruker-spesifikk klientnøkkel (326 mipkey) kryptert med den generelle krypteringsnøkkelen (323 enckey) sammen med den generelle krypteringsnøkkelen (323 enckey) kryptert med en kryptografisk nøkkel (327), at klienten (100) er anordnet til å dekryptere den generelle krypteringsnøkkelen (323 enckey) med kryptografisk nøkkel (327) og dekryptere klient krypteringsnøkkelen (322 clikey), lisens nøkkel (324 licinfo) og øvrig informasjon oversendt fra tjeneren med den generelle krypteringsnøkkelen (323 enckey), og at klienten (100) er videre anordnet til å benytte klient krypteringsnøkkel (322 clikey) til signering av senere henvendelser til tjeneren.

Det arrangement som beskrevet i avsnittet over kan videre omfatte at en klient (100) som alt er registrert som beskrevet i 1 og benytter den bruker-spesifikke tjenesten ved mottak av feilkode ved bruk av tjenesten, videre er anordnet til å overføre fra terminalen

(100) til tjeneren (103) en forespørsel om tjenesteaktivering der en terminal-spesifikk identitet (320) og den valgte bruker-identitet (321) oppgis i forespørselen, og at denne forespørselen er signert av klienten med klient krypteringsnøkkel (322 clikey), at tjeneren (103) er anordnet til å kontrollere at forespørselen fra klienten (100) er signert med klient-krypteringsnøkkel (322 clikey), og dersom forespørselen er korrekt gjennomføres lisens-aktivering og dersom forespørselen er signert feil behandles forespørselen som en anonym henvendelse som beskrevet i punkt 1, at tjeneren (103) er anordnet til å foreta lisens aktivering ved å be brukeren om å akseptere tjenestevilkår og oppgi betalingsinformasjon, og at tjeneren (103) er videre anordnet til å oversende betalingsinformasjon til kredittkort-selskap (104), ved aksept overføres oppdatert lisensinformasjon til klienten (100) og AAA-database oppdateres og ved avslag avvises forespørselen.

Videre kan arrangement som beskrevet over være slik innrettet at tjenesten er Mobil IP og feilkoden er feilmelding 131 fra en Mobil IP hjemmeagent (101).

Videre kan arrangement som beskrevet over være slik innrettet at klienten (100) også er anordnet til å overføre klient modell/versjonsnummer, operativsystem type og operativsystem versjon, foretrukket språk og årsak for henvendelsen (103).

Videre kan arrangement som beskrevet over være slik innrettet at tjeneren (103) krever at det også oppgis en gyldig email-adresse eller gyldig mobilnummer som senere kan benyttes til å kontakte kunden.

Videre kan arrangement som beskrevet over være slik innrettet at tjeneren (103) tillater klient (100) reinstallasjon ved utstedelse av en kopi av konfigurasjonsinformasjon når forespørselen inneholder en kjent terminal spesifikk identitet (320) og brukeren oppgir et brukernavn (321) som eksisterer fra før.

Videre kan arrangement som beskrevet over være slik innrettet at tjeneren tillater lisens-overføring ved utstedelse av en ny signert konfigurasjonsinformasjon når forespørselen inneholder en ny terminal spesifikk identitet (320) og brukeren oppgir et brukernavn

(321) som eksisterer fra før.

Videre kan arrangement som beskrevet over være slik innrettet at gjentatt lisens-overføring tillates kun et bestemt antall ganger ved å sette en sperre for antall lisens-overføringer som er tillatt per registrerte brukernavn (321).

Videre kan arrangement som beskrevet over være slik innrettet at tjeneren (103) blokkerer for utstedelse av konfigurasjonsinformasjon når forespørselen inneholder en kjent terminal spesifikk identitet (320) og brukeren oppgir et nytt brukernavn (321).

Videre kan arrangement som beskrevet over være slik innrettet at klienten (100) kan detektere at det er registrert en apparatidentitet, kalt "device-id", som ikke har gyldig lisens, og tilbyr brukeren automatisk opprettelse av konfigurasjon og lisens.

Videre kan arrangement som beskrevet over være slik innrettet at klienten (100) kan detektere versjon av konfigurasjonsdata i klienten ikke stemmer overens med klientprogramvare versjon, og tilbyr brukeren automatisk oppdatering av konfigurasjonsinformasjon til riktig versjon.

Videre kan arrangement som beskrevet over være slik innrettet at klienten (100) kan detektere at det ikke er mulig å nå hjemmeagenten (101) og redirigerer brukeren til en webside som tilbyr assistanse til konfigurasjon.

Videre kan arrangement som beskrevet over være slik innrettet at tjeneren (103) kan utstede en "provider section" for 3. part som kan gi 3dje part anledning til å utstede lisenser, uten at 3. part får adgang til å endre service provider og URL for konfigurasjon.

Videre kan arrangement som beskrevet over være slik innrettet at tjeneren (103) kan utstede en "provider section" for 3. part som kan gi 3dje part anledning til å utstede signerte profiler, uten at 3. part får adgang til å utstede lisenser for klientprogramvare. Videre kan arrangement som beskrevet over være slik innrettet at konfigurasjonen fra server (103) til klient (100) er signert av server for å unngå feilaktig konfigurasjon og tjeneste-nekt-angrep mot klienten.

Systemoversikt

Om vi bruker Mobil-IP som det bruker-spesifikke tjenesteekesempelet, kalt "SmartRoaming" i resten av dokumentet, består systemet av fem forskjellige komponenter.

100 Mobile IP klient

101 Mobile IP Hj emmeagent

102 AAA-tjener (f.eks. RADIUS-basert)

103 Administrasjonstjener

104 Kreditt-kortbetalingstjener (drevet av betalingsformidler)

Figur 1 beskriver logikken i interaksjon mellom komponentene. Klienten samhandler med Mobil-IP-agenten i følge de vanlige IETF-standarder over standardgrensesnitt markert med 10 i figuren. Nøkkelen til systemets virksomhet er hvordan klienten kommuniserer med leveransetj eneren over de proprietære grensesnittet 20 beskrevet i den foreliggende beskrivelsen. Merk at kommunikasjonsveiene markert med 15 tilsvarer rjenestetrafikkflyt, og veiene markert med 25 tilsvarer til tilsvarer tj enestekontrollflyt.

Kommunikasjon mellom klient og leveransetj eneren er implementert som et proprietært grensesnitt over http(s). Den innebygde nettleser i klient-terminalen (100) er brukt til å forespørre, fremvise og laste ned informasjon. All logikk er implementert på tjenersiden

(103). Hver transaksjon starter med at klienten sender en forespørsel til tjeneren. Tjeneren avgjør korrekt status for klienten og genererer en serie med re-dirigeringer tilsvarende de ulike steg i hver transaksjon som er planlagt for klienten. Noen transaksjoner starter en http(s)-nedlasting som det endelige steg. Innholdet er markert (ved bruk av "Content-Type"- hode) som en spesifikk MIME-applikasjonstype ("application/xxxx"). Klientprogramvaren vil registrere seg selv ved installasjon til å håndtere denne type innhold, f.eks. ved hjelp av en nettleser plug-inn for å unngå dialogen i forbindelse med nedlasting av fil for konfigurasjonsinformasjonen, som normalt tilbys av nettleseren. Interaksjonen mellom klienten (100) og leveransetj eneren (103) avhenger av en eller flere av de følgende nøkkelbetingelser. 1 Klienten (100) initierer en forespørsel til tjeneren (103) i situasjoner som (i) dersom klienten ikke har en gyldig konfigurasjon, (ii) dersom brukeren velger "Min Konto" fra klientbrukergrensesnitt, eller (iii) hver gang klienten får en Mobil-IP-feil 131 (autentiseirngsfeil) fra hjemmeagenten (101). Den siste situasjonen kan provoseres fra tjeneren for å få oppmerksomhet fra klienten. Se seksjonen 'Telles aspekter av tjenesten" for en full liste av situasjoner som kan utløse sending av en forespørsel. 2 Merk at forespørselen alltid starter med at klienten sender en "solicit"-forespørselmelding til tjeneren og mottar nøkkelinformasjon som adressen til den riktige leveransetj eneren, et sikkerhetstoken (utfordring) og en forhånds-formulert forespørselstreng som skal brukes i den etterfølgende forespørselen. På denne måten kan flere administrasjonstjenere benyttes og tjenerrnigrering og lastbalansering kan oppnås. 3 En programvarelås i klienten som kan representere tre tilstander (i) den initielle tilstanden tilsvarende en fersk installasjon og ingen tidligere aktiveringsforsøk, (ii) låst tilstand som tilsvarer prøvetidsfase og (iii) opplåst tilstand som tilsvarer fulle lisensrettigheter. 4 En kapasitet i klienten til å gjenkjenne SmartRoaming-profiler blant settet av alle profiler. Muligheten til å arbeide spesifikt med SmartRoaming-tjenesten for slike profiler. Profilen er klassifisert som en SmartRoaming-profil hvis og bare hvis dens profil-GUID (fagtermakronym for: "globalt unik identifikator") matcher den som er lagret i leverandørens konto og dens "hash" er lagret i leverandør-kontoinformasjonen. 5 Konfigurasjonen sendt fra tjeneren til klienten er signert av konfigurasjonstjeneren, for å unngå feil konfigurasjonsinformasjon og tjenestenektangrep ved falsk konfigurasjonsinformasjon.

De viktigste transaksjonene over leveransegrensesnittet er:

1 initiell tjenesteaktivering

2 lisensaktivering etter utløp av prøveperioden.

3 fornyelse av tjenesten etter slutten av hver abonnementsperiode

Merk at tjenesteaktivering er en forutsetning for lisensaktivering. Videre må den initielle tjenesteaktiveiingen komme fra mMterminalen som skal motta konfigurasjonsdata og kjøre Mobil-IP-klienten. Andre tjenesterelaterte oppgaver, som lisensaktivering, tjenestefornyelse, etc. kan komme enten fra målterminalen eller fra en annen terminal (typisk en PC) via det separate kontoadministrasjonsnettgrensesnittet. Interaksjonen mellom klienten og leveransetj eneren er videre styrt av en sikkerhetsmodell basert på det følgende: 1 Tjenestekonfigurasjonsdata lagret på klienten er signert av leveransetjeneren, og gjør derved dataene innbruddssikre. 2 Kritiske data (som brukerakkreditiver og nøkler) lagres på klienten i kryptert format. 3 Klient-tjener-kommunikasjonen er signert og kryptert, og hindrer derved inntrengningsforsøk fra ondsinnede klienter. 4 Nøkkeladministrasjon er sikker, og forhindrer derved avsløring av nøkkelinformasjon.

Felles forhold ved tjenesten

De følgende underavsnitt beskriver systemaspekter som er felles både for klient og tjener. Mer detaljert informasjon for respektive klient- og tjenersidekomponenter er gitt i senere avsnitt.

Kommando- sløyfe

Klienten må ha så lite innebygd intelligens som mulig. Den overordnede kontrollen må være på tjenersiden. Hensikten er å forenkle klientimplementasjonen og ha et design som er fleksibelt for endring også etter at klienten er installert.

Kommando-sløyfen har to faser; den første fasen (som kalles "solicit"-fase) er initiert direkte av klienten (ikke via nettleseren), og dokumentet som returneres har en veldig enkel struktur, som vist i eksemplet i Tabell 1. Dette dokumentet "parses" av klienten og informasjonen er brukt i den etterfølgende fasen som utføres av nettleseren. "Solicit"-fasen returnerer informasjon som omdirigeringsadresse, URL som skal brukes og utfordrings-verdier (fagterm: "challenge"). Merk at utfordringsverdien er gyldig bare en kort tid, f.eks. et par minutter, for å få til beskyttelse mot gjentatt sending.

Solicit-fasen gjøres som den første transaksjonen i forespørselen fra klienten til leveransetj eneren, og gjør det mulig for tjenesteleverandør å kontrollere IP-adressene som brukes av tjenesten, og formulere master-URL til bruk for senere forespørsler. På denne måten kan nye tjenere introduseres, og tjenstemigrasjon kan gjøres uten noen endringer til klienten.

Merk at klienten kun åpner en URL (kalt "solicit URL"), som kan åpnes i anonym eller navnet modus. Tjeneren responderer med en enkel URL (som inneholder "token" som klienten vil parsere og erstatte, f.eks. enhets-identifikator (320), brukernavn, utfordringsverdi, signatur, klientversjon, årsak for forespørselen), og starter deretter en nettleser med den resulterende URL. Fra dette punkt interagerer klienten ikke med leveransetjeneren, alt gjøres i nettleseren (inntil tiden da nettleseren, dersom det trengs, mottar en ny konfigurasjon, eller Mobil-IP-forbindelsen restartes).

HTTP(S)-grensesnittet mellom klient og leveransetj ener er basert på å alltid forespørre den samme basis-URL. To forskjellige parametersett kan legges til, avhengig av forespørseltype, som f.eks. anonym eller navnet, som beskrevet nedenfor. Tjeneren håndterer forespørsler i et angitt adgangspunkt i web-tjeneren. Tjeneren avgjør den øyeblikkelige status for klienten og planlegger den korrekte transaksjonen. Tjeneren responderer med (en serie av) re-dirigeringer, hver med en mer spesifikk URL, avhengig av den utstedte transaksjonstypen. Hver transaksjon kan resultere i en HTTP-nedlasting dersom klientens konfigurasjon trenger oppdatering. Klienten vil sende en ny forespørsel igjen bare ved bestemte forhold som beskrevet under.

En forespørsel fra klienten kan være enten (i) anonym eller (ii) navnet. Den første er brukt når klienten ikke har noen tidligere konfigurasjonsdata, typisk en fersk installasjon, eller at konfigurasjonsdata har blitt modifisert, f.eks. ved en signaturkontroll som feiler. I dette tilfelle kan ikke noen kontoidentifikator legges til forespørselen (derfor anonym). Det andre tilsvarer tilfellet når klienten har et sett med gyldige konfigurasjonsdata for en gitt SmartRoaming tjenestekonto. I dette tilfellet vil identifikatoren assosiert med kontoen legges til forespørselen (derfor navnet). En navnet forespørsel trigges (i) dersom klienten ikke har gyldig konfigurasjon, (ii) dersom brukeren velger "Min konto" fra klientens brukergrensesnitt, (iii) klient-versjonen er annerledes enn konfigurasjons-versjonen, eller (iv) når klienten mottar Mobile-IP-feil 131 (autentiseirngsfeil) som signaliseres til klienten mens den er i bruk for å få oppmerksomhet.

Leveransetj eneren gjør dette midlertidig ved å invalidere autentiserings-data lagret i AAA-tjeneren (102) for den aktuelle brukerkonto. Tjeneren kan planlegge et sett med aksjoner for klienten før klienten gis beskjed. Når klienten har fått beskjed, sender klienten en forespørsel til tjeneren, og utfører den nødvendige transaksjonen. Det detaljerte hendelsesforløpet er som følger: 1. Tjeneren trenger (ønsker) oppmerksomhet fra klienten, f.eks. for å informere om at en prøveperiode er utløpt. 2. Tjeneren endrer midlertidig autentiserings data i AAA-tjeneren (102) til en ugyldig verdi som ikke stemmer med den korresponderende profil-instillingen i klienten. 3. Ved neste re-registrering fra klienten provoseres en feilkode 131, i henhold til

Mobil-IP-standarden definert i IETF RFC3344.

4. Klienten tar en feil 131 for en SmartRoaming profil som et signal og at tjeneren ønsker dens oppmerksomhet, og sender en navnet forespørsel. 5. Tjeneren avgjør hvilken transaksjon som skal startes (f.eks. en utløpt prøveperiode) og utfører en kjede av re-dirigeringer i henhold til dette.

6. Transaksjonen fullføres.

7. Klienten fortsetter normal Mobil-ff-operasjon.

8. Klienten kan selv ta initiativ til kontakt med tjeneren ved bestemte kriteria som beskrevet tidligere.

For å sikre korrekt respons via kommandosløyfen ved feil 131 er det en nøkkelforutsetning at agenten ikke lagrer akkreditiver midlertidig (tilsv, fagterm: "caching"), men alltid henter disse direkte fra AAA-tjeneren (102). Videre, AAA-tj ener-mfrastruktur må skalere sammen med agentmfrastruktur (101) for å sikre rask respons i kommunikasjonen mellom disse to komponentene.

Redirigering til et tjenesteleverandørsted

Når brukeren starter en nettverksavhengig applikasjon og velger Mobil IP forbindelsen, kan Mobil IP klienten trenge å redirigere brukeren til en Mobil IP tjenesteleverandørs nettsted. Ved dette tilfelle, vil klienten vise en melding der brukeren spørres om å akseptere eller ikke akseptere redirigeringen. Meldingen som vises bør varieres i henhold til årsaken til redirigeringen. Tabellen under viser mulige årsaker til redirigering.

Aksjon som tas av klienten og meldingen som vises i hvert av tilfellene over er som følger. Merk at disse forholdene bør håndteres i klienten i samme rekkefølge som i listen. 1. Klienten etablerer en standardleverandørpostering. Derfor trengs ikke redirigering og ingen melding vises. 2. Klienten enten etablerer automatisk en standardleverandørpostering (hard-kodet) eller viser følgende redirigeringsmelding: <Tjenesteleverandør> kontaktdata er ikke gyldig Vil du lagre dem?

3. Klienten viser følgende melding:

Mobile IP er ikke aktivert for din terminal. Vil du aktivere den med <Standard-Tjenesteleverandør>?

4. Klienten viser følgende melding:

Din Mobil IP lisens er ikke gyldig.

Vil du gjenskape den fra <Leverandør>?

5. Klienten viser følgende melding:

Du har ikke en profil

Vil du hente en fra <Leverandør>?

6. Klienten viser følgende melding:

Din aktive profil er ikke gyldig

Ønsker du å gjenskape den fra <Leverandør>

7. Klienten viser følgende melding:

Din <Leverandør> konto er suspendert

Vil du gjenoppta operasjon?

8. Klienten viser følgende melding:

Din Mobil IP lisens er ikke gyldig.

Vil du gjenskape den fra <Leverandør>?

9. Klienten viser følgende melding:

Dine kontodata stemmer ikke med din Mobil IP klientversjon Vil du oppgradere din konto til riktig versjon?

10. Klienten viser følgende melding:

Du har en gyldig <Leverandør> profil, men terminalen er ikke i stand til å nå hjemmeagenten. Du redirigeres til <Leverandør> for assistanse med å finne feilen.

I alle meldingstekstene over er <Leverandør> et felt for leverandørnavnet (SmartRoaming.com, for eksempel).

Et viktig poeng vedrørende hvordan 131 kan provoseres; tjeneren må bruke en (ugyldig) nøkkel for å provosere 131. Imidlertid må denne ugyldige koden også kjennes av klienten. Vi bruker det krypterte passordet som den ugyldige nøkkel. Grunnen til dette er at klienten må være i stand til å verifisere MIP-autentikatoren av Mobile IP RRP-meldingen som gir feilkode 131, derav verifisere at den kommer fra hjemmeagenten som forventet. Dette er for å unngå av klienten blir sårbar for DoS-angrep.

Tjenesteaktivering

Tjenesteaktivering referer til prosessen med å etablere et nytt abonnement og starte en prøveperiode. Registreringen er umiddelbart fulgt av å laste ned SmartRoaming konfigurasjonsdata. Begrepet re-aktivering er brukt når konfigurasjonsdata fra en tidligere aktivering er tapt eller endret i terminalen. En forespørsel kan sendes til tjeneren og resultere i en gjentatt nedlastning. Prosessen med å låse opp klienten ved å fortsette tjenesteabonnementet etter prøveperioden kalles lisensaktivering og er diskutert i et senere avsnitt.

Når aktivering er startet, vil klienten starte standardnettleser i terminalen (100) og vil dirigeres til en registrerings-side som ber om (blant annet) en brukernavn/passord-kombinasjon.

Dersom leveransetj eneren (103) avgjør at det ikke finnes en konto med den oppgitte terminal id, må en ny konto lages og et nytt sett med konfigurasjonsdata må lastes ned. Dette tilsvarer initiell aktivering og starter prøveperioden. Etablering av konti må imidlertid gjøres avhengig av en kontroll at lås-status for klienten som forespør ikke indikerer at klienten allerede er i en prøveperiode under et annet navn.

Tjenersiden (103) må lagre informasjon om etableringen av hver konto og holde kontroll med tiden deretter. Dersom navnet finnes og passordet stemmer, gjøres re-aktivering av en eksisterende konto. De samme konfigurasjonsdata lastet ned ved den originale aktiveringen må da lastes ned igjen og overskrive den lokale kopi. Dette representerer en fortsettelse av prøveperioden. Tidspunktet for initiell aktivering må lagres.

Dersom brukeren eksisterer og passordet ikke stemmer, må det anses å være et ikke-unikt brukernavn. Brukeren må da spørres om å velge et annet navn. Tjeneren bør da tilby noen alternativer som er unike, men fortsatt ligne på brukerens opprinnelige forslag.

Ved tilfellet av en SmartRoaming reaktiveringforespørsel, må tjeneren først sjekke om brukerkontoen er en prøve-konto eller en fullt lisensiert tjenestekonto. I det førstnevnte tilfellet må tjeneren sjekke lås-status som rapporteres av klienten. Dersom dette ikke stemmer, må klienten gjøre en forespørsel til tjeneren for å endre sin lås-status.

Signalering for tjenesteaktivering via en anonym forespørsel er beskrevet i figur 2. Merk at 200 angir tjenesteleverandørens ansvarsområde, mens 210 angir kredittkort-selskapet. Den initielle forespørsel representerer "soliciation" fasen, og gjør det mulig for tjenestetilbyderen å formulere en URL som deretter brukes av klienten, så vel tjener-adresse og et "token" som brukes for å unngå tjenestenektangrep (fagterm: "Denial of Service"). Når "solicif-reponsen er mottatt, genererer klienten en forespørsel til tjeneren, som vil gjøre en redirigering til aktiveringsside. Når denne siden er fylt ut, genereres det en konto. En annen redirigering returneres da for at klienten tilslutt kan hente de resulterende konfigurasjonsdata.

Den følgende sekvensen er illustrert i figur 2:

201 Solicit-forespørsel fra klientprogramvare

202 Solicit-respons til klientprogramvaren

203 Anonym forespørsel fra klientens nettleser

204 Redirigering

205 Tjenesteaktiveringsside

206 Oppdatere AAA-informasjon

207 Redirigering

208 Forespørsel om konfigurasjon

209 Konfigurasjonsdatanedlastning (nettleser engasjerer klientsoftware automatisk)

Lisensaktivering

Kommandosløyfen vil fange situasjonen der et aktivt SmartRoarning-abonnement er utløpt etter en prøveperiode. Når dette hender vil klienten bli redirigert til en lisensieirngs-side. De allerede eksisterende brukeraavnverdiene assosiert med den eksisterende SmartRoaming-profilen vil bli sendt direkte i en navnet forespørsel. Ved å akseptere vilkår for tjenesten og presentere betalingsinformasjon, kan brukeren fortsette tjenesteabonnement et og oppnå en full programvarelisens. Brukernavnet er kobling mellom betalingstransaksjonen og tjenesteabonnementet. Etter betaling må tjeneren oppdateres med ny kontostatus og den nye lisens-låsen vil bli lastet ned. Merk at det ikke trengs noen ny nedlasting av profilen på dette punkt. Brukeren kan fortsette å bruke den installerte programvaren og SmartRoaming-profilen.

Dersom brukeren nekter å betale har vedkommende ikke rett til å fortsette å bruke programvaren, og tjenesteabonnementet blir invalidert. Tjenestekontoen blir imidlertid ikke fjernet. Brukeren kan til enhver tid starte en lisensaktiveringsprosess for å fortsette tjenesteabonnementet og få en full programvarelisens.

Signalering for lisensaktivering er beskrevet i figur 3. Dersom vi forutsetter at denne skjer under Mobil IP operasjon, vil leverandørtjeneren (103) invalidere kontoen i AAA-tjeneren (102) og den neste Mobil IP registreringsforespørselen til klienten vil oppleve en feil 131.1 respons til dette vil klienten sende en navnet forespørsel. Dersom vi forutsetter at prøveperioden er utløpt, vil klienten (100) bli redirigert til en lisensaktiveringsside. Etter å komplettere kredittkort-transaksjonen med kredittkort- selskapet

(104) og oppdatering av kontoen i AAA-tjeneren (102), genereres en ny redirigering og klienten kan laste ned oppdaterte konfigurasjonsdata.

Den følgende sekvensen er illustrert i figur 3.

220 MlP-registreringsforespørsel

221 AAA-forespørsel

222 AAA-respons

223 MIP-registreirngsrespons (131)

224 Solicit-henvendelse fra klientprogramvare

225 Solicit-respons til klientprogramvare

226 Navnet forespørsel fra standard-nettleseren i klienten

227 Redirigering

228 Lisensaktiveringsside

229 Kjedittkort-transaksjon

230 Transaksjon OK

231 Oppdatere AAA-informasjon

232 Redirigering

233 Konfigurasjonsdatanedlastingsforespørsel

234 Konfigurasjonsnedlasting (nettleser vil automatisk engasjere klientprogramvare)

Fornyelse av tjeneste

Kommandosløyfe-mekanismen vil fange situasjonen også når et aktivt SmartRoaming-abonnement er utløpt. Når dette skjer vil klienten oppleve en Mobil IP feil nummer 131, klientforespørsel vil bli initiert og terminalnettleseren vil bli redirigert til en betalingsside for å fortsette hans/hennes abonnement. Merk at denne siden vil være annerledes enn lanseringsaktiveringssiden siden brukeren allerede har skaffet en lisens. Brukeren vil fortsette å bruke den samme installerte programvare og SmartRoaming-konfigurasjonen, derfor vil ingen nye data bli nedlastet i dette stadiet. Sekvensdiagrammet er svært likt lisensaktiveringstransaksjonen.

Dataflyt og sikkerhetsmodell

Kommunikasjonen mellom klienten (100) og tjeneren (103) er sikret av https. Leveransetjeneren må installere et webtj ener sertifikat utstedt av en velkjent sertifikat-autoritet. Klienten må bare kommunisere med leveransetjeneren om den har et gyldig sertifikat for navnet smartroaming.com.

En terminal-id (320) som unikt identifiserer klientinstallasjonen må alltid legges til forespørselen. Dette gjelder både anonym og navnet forespørsel, terminal-id kan hentes fra en vilkårlig kilde i terminalen. For en Symbian-terminal kan det være en IMEI-verdi. For en PC kan det være prosessorens serienummer. Formatteringen av terminal-id er åpen, dvs. at den må anses som en variabellengde-tekststreng. Tjenesteleverandør-seksjonen er signert. Tjeneste-Aktiverings-URL er del av denne seksjonen og derfor signert. Denne kan være en ikke-https URL. Dersom det er en https URL, imidlertid, kan det kontrolleres at tjeneren har et sertifikat som matcher URL som etterspørres (utstedt av en CA som har "root" sertifikat installert i klienten). Andre informasjonselementer som alltid må legges til som parametere i enhver forespørsel er:

1. Klient (Mobile IP) programvareversjon

2. Klient OS plattform og versjon

3. Klient terminal_id

4. Klient terminal modell

5. Foretrukket språk

6. Årsak til henvendelsen

Virkningen av å sende over terminal-id (320) i en anonym henvendelse er at tjeneren kan avgjøre eksakt lisensieringstilstand. Ved å sammenligne den mottatte tjeneste-id med databasen av registerte tjeneste-id, og i tillegg ta hensyn til brukernavnet som ble levert i det etterfølgende registreringssteg, kan tjeneren skille mellom de mest vanlige scenario nummerert 1-4 i tabellen under (se tabell 2 for en mer komplett oversikt)

En navnet forespørsel starter alltid med en "solicit"-fase, som implementerer en "challenge-response" del av en navnet henvendelse. En "utfordringsverdi" fra "solicit"-fasen må inkluderes i de etterfølgende http-henvendelsene, dette for å unngå angrep ved gjentatt avspilling.

En navnet forespørsel inneholder brukernavnet i tillegg til terminal-id. I kontrast til den anonyme henvendelsen, er forespørselen selv også signert. Signeringen er et bevis på identiteten til klienten og tjeneren kan fortsette direkte til brukerkonto uten behov for manuell brukerautentisering. Sikkerheten er basert på det faktum at tjeneren ved initiell aktivering vil generere en klientnøkkel og returnere denne til en klient. Tjeneren vil også bruke den samme verdien til å verifisere at henvendelsen matcher med kontonavnet, og derved kommer fra den samme klienten som gjorde den opprinnelige aktiveringen, basert på en tjener-generert utfordring (challenge) og brukernavnet.

Flerleverandørmuligheter.

Merk at tjenesten kan tilby støtte for flere tjenesteleverandører. Ideen er at en eier av en tjeneste (f.eks. Birdstep) kan utstede signerte tjeneste-seksjoner for et sett leverandører, hver leverandør har deres egen (unik) signeringsnøkkel (privat/offentlig) par. Leverandørtjeneste-seksjonene er igjen beskyttet ved at "root"-nøkkelpar bare kjent av Birdstep. En lang rekke leverandør-definisjoner kan være pre-konfigurert i klienten ved utsending. Ved å bruke denne mekanismen, kan leverandører signere konfigurasjoner og kontrollere URL for nedlasting. Merk at de samme konfigurasjonsmekanismene kan brukes til å betjene flere lisenstakere, og tillate kunder som for eksempel terminalprodusenter å utstede klientlisenser for bruk av tjenesten og fortsatt la terminalen være enkelt konfigurerbar for multiple tjenesteleverandører.

Anonyme https- forespørsler

Dataflyt og sikkerhetsaspekter ved å sende anonyme forespørsler er illustrert i figur 4. Merk at diagrammet bare fanger det første (henvendelse) steg og det endelige (nedlasting) steg i kjeden av transaksjoner. Mellomsteg med redirigering er undertrykket i illustrasjonen. Videre fokuserer illustrasjonen på hvordan tjeneste-id-parameteren håndteres. Håndteringen av andre parametere (klientversjon og klient-operativsystemplattform) vises ikke i diagrammet. Fargekoden er som følger:

1 hvit identifiserer klartekst (original) verdier

2 grå representerer signaturverdier

3 skravert representerer krypterte verdier

Bokser med sort ramme representerer permanentlagrede verdier (306). Bokser med stiplet ramme representerer transientgenererte verdier (305). Den venstre del av figuren tilsvarer klientsiden og den høyere del av figuren tilsvarer tjenersiden. De grå fete pilene indikerer trafikk over https-grensesnittet (308/309). De sorte kurver og piler viser hvordan ulike elementer er inngang og utgang fra signering og krytperingsoperasjoner. De grå firkantene tilsvarer signaturkalkulering (304). De små sorte sirklene korresponderer til kryptering (302), og hvite sirkler indikerer dekryptering (301). Konfiguasjonsstrukturene vi tar i betraktning her er i hovedsak:

1 Kontoinformasjon (acctinfo)

2 Mobile IP profilinnstilinger (profile)

Figur 4 has den følgende betydning av symbolene:

301 dekryptering

302 kryptering

303 verifiser

304 signer

305 transientgenerert

306 Permanent lagret

307 Kryptografisk hemmelig nøkkel

308 https forespørsel (parameterisert)

309 https nedlasting (mime-kodet)

310httpmsg

311 acctinfo

312 profil

Figur 4 viser de følgende dataelementene:

320 terminal-id

321 userid

322 clikey

323 enckey

324 licinfo

325 signatur

326 mipkey

327 kryptografisk hemmelig nøkkel

328 signeringsnøkkel

Etter å ha avgjort lisens-status (ref. tabellen over) vil leveransetjeneren vite dersom det allerede er en brukerkonto eller om en ny konto må lages. I tilfelle (4) vil tjeneren enkelt returnere eksisterende konfigurasjonsdata til klienten for dens gjenskapelse av den originale konfigurasjon. I tilfelle (3) vil terminal-id erstattes og den resterende informasjonen bli oppdatert etter rekalkulasjon av de nødvendige signaturer og krypterte verdier. I tilfelle (1) vil en ny konto etableres og fylles med riktig informasjon før den blir kalkulert. Brukernavnet tas fra skjema som blir fremvist i registreringssiden.

En klientnøkkel (clikey) vil genereres som en kryptografisk tilfeldig nøkkel. Nøkkelen er unik og vil bli brukt av klienten til å signere henvendelser og av tjeneren for å verifisere autentisiteten. Klientnøkkelen er videre kryptert med en annen nøkkel (enckey) før nedlasting til klient. Tjeneren lagrer klartestverdi av clikey. Krypteringsnøkkelen (enckey) er også generert som en kryptografisk tilfeldig nøkkel. Denne nøkkelen er kryptert med en kryptografisk hemmelig nøkkel som også brukes for å signere data som sendes ned til klienten.

Lisensinformasjonen (licinfo) kan inneholde vilkårlig tekstlig informasjon. Som et minimum må den reflektere den nåværende lisensieirngsfase (prøveperiode eller full lisens) for at klienten skal vite hvordan den skal operere. LisensStatus er et heltall (0=Ukjent, l=Prøve, 2=Full) og parameteren "Licenselnfo" kan være en vilkårlig tekst. For øvrig kan lisensinfo inneholde data som lisensiert bruker, utløpsdato, osv. Disse detaljene er for informasjonsformål og vil ikke brukes av klienten (bortsett fra å vise dem frem på skjermen). Mobil-IP-profilen er fylt inn i henhold til hjemmeagenten. En NAI genereres fra kontoens brukernavn legges til området ("smartroaming.com"). En Mobil-Ip-autentiseringsnøkkel (mipkey) er generert fra tilfeldige data og kryptert med enckey før den lastes ned til klienten. Tjeneren lagrer kun klartekstverdien av nøkkelen. NAI og mipkey er sendt videre også til AAA-tjeneren.

Hensikten med å kryptere mipkey er å forhindre brukere fra å distribuere detaljene i en SmartRoaming-profil til offentlig og potensiell misbruk i Mobil-IP- klienter andre enn de SmartRoaming-klientene som f.eks. Birdstep tilbyr. Hensikten med å kryptere klikey er å gjøre det vanskeligere å "spoofe" klient-henvendelser. Enhver angriper må da gjette både krypteringsalgoritmen og signeringsalgoritmen. De ukrypterte verdiene av disse nøklene må bare lagres i volatilt minne i klienten.

Signaturer kalkuleres over hele "acctinfo"- og profil-strukturer. Krypterte verdier må inkluderes i kalkulasjonen i stedet for å bruke de korresponderende klartekst-verdier. Dette fordi klienten bare vil kjenne de krypterte verdiene, og signaturen må matche dette. Klienten vil bruke signaturene til å verifisere at den nedlastede konfigurasjonen er autentisk før delene benyttes.

Navnet https- henvendelse

Dataflyt og sikkerhetsaspekter av å sende en navnet henvendelse er illustrert i figur 5 og 6. Figur 5 tilsvarer eksemplet når ingen konfigurasjonsdata trenger å lastes ned. Figur 6 beskriver eksemplet når enten profilkonfigurasjon eller kontoinformasjon trengs å oppdateres.

Før sending av en navnet forespørsel må klienten verifisere konfigurasjonsstrukturene mot signaturene for å forsikre at de er autentiske. Den kryptografiske hemmelige nøkkelen 327 må brukes for å verifisere strukturene. Signaturnøkkelstrukturen 328 kan brukes til å verifisere de andre konfigurasjonsstrukturene. Klienten må da verifisere at den har en gyldig lisens ved å sammenligne terminal-id (320) i "acctinfo"-strukturen med den virkelige id rapportert av terminalen selv. Signaturnøkkelen brukes i denne kalkulasjonen og clikey må dekrypteres først ved bruk av enckey. Dersom lisens-veriflkasjonen er OK kan klienten fortsette med å sende navnet henvendelse.

Den navnede forespørselen vil inkluderer brukernavnet sammen med terminal-id. Parameterlisten i forespørselen vil være signert ved bruk av parameteren clikey (igjen etter dekryptering av nøkkelen) og signaturen føyd til parametrene i tillegg til en utfordrer-verdi. På tjenersiden brukes terminal/bruker-id-kombinasjonen til å slå opp kontoinformasjonen. Den korresponderende clikey vil bli brukt til å verifisere signaturen til forespørselen. Dersom de alle stemmer, er kontoen verifisert og tjeneren kan fortsette direkte uten ytterligere brukerautentisering. Dersom verifikasjonen feiler er forespørselen ikke gyldig og må droppes.

For tilfellet med nedlasting (figur 6) er kryptering og signaturkalkulasjon nøyaktig den samme som en anonym forespørsel.

Mobil- IP- registrering

Dataflyt og sikkerhetsaspekter ved å sende Mobil-IP-registreringsforespørsel er vist i figuren under. Kommunikasjon av UDP/434 med Mobil lp agenten representerer et annet signaleringsplan enn HTTP(S)-kommunikasjonen med leveransetjeneren. Mipkey må dekrypteres i klienten for å kalkulere autentikatoren til Mobil IP registreringsmeldingen. Dette krever i sin tur at enkey er dekryptert. På tjenestesiden (hjemmeagenten i dette eksemplet), hentes klartekstnøkkelen fra RADIUS-tjeneren og autentikatoren verifiseres.

Claims (15)

1. Klient/tjener arrangement for sikker og automatisk konfigurering av en trådløs terminal med en klient (100) for et lisensnøkkelavhengig, bruker-spesifikt tjenesteabonnement tilveiebrakt av en tjenesteleverandør gjennom fremstilling og bruk av krypteringsnøkler og bruker-spesifikk informasjon i en tjener (103), og hvor tjeneren (103) er anordnet i en vertsdatamaskin tilsluttet tjenesteleverandøren,karakterisert vedat klienten (100) er anordnet til å overføre fra terminalen en forespørsel om aktivering av det brukerspesifikke tjenesteabonnementet til tjeneren (103) omfattende en terminal-spesifikk identitet (320) og en bruker-identitet (321) innmatet av brukeren, og at tjeneren (103) er anordnet til a) å aktivere det forespurte lisensnøkkelavhengige, brukerspesifikke tjenesteabonnementet ved å generere en lisensnøkkel (324 licinfo), en klient-krypteringsnøkkel (322 clikey), en bruker-spesifikk klientnøkkel (326 mipkey) og en generell krypteringsnøkkel (323 enckey) for benyttelse til å kryptere data som oversendes mellom tjeneren og terminalen, b) å kryptere den generelle krypteringsnøkkelen (323 enckey) med en kryptografisk hemmelig nøkkel (327), c) å lagre bruker-identitet (321), terrriinal-spesifikk identitet (320) og bruker-spesifikk klientnøkkel (326) i en database, og d) å returnere til klienten (100) lisensnøkkel (324 licinfo), klient-krypteringsnøkkel (322 clikey), bruker-spesifikk klientnøkkel (326 mipkey) kryptert med den generelle krypteringsnøkkelen (323 enckey) sammen med den generelle krypteringsnøkkelen (323 enckey) kryptert med en kryptografisk hemmelig nøkkel (327), og at klienten (100) er anordnet til å konfigurere terminalen for det lisensnøkkelavhengige, brukerspesifikke tjenesteabonnementet ved å dekryptere den generelle krypteringsnøkkelen (323 enckey) med den kryptografiske hemmelige nøkkelen (327) og å dekryptere klientkrypteirngsnøkkelen (322 clikey), lisensnøkkelen (324 licinfo) og konfigureringsinformasjon oversendt fra tjeneren med den generelle krypteringsnøkkelen (323 enckey), og at klienten (100) er videre anordnet til å utnytte i terminalen konfigurert med den dekrypterte lisensnøkkelen og den dekrypterte konfigureringsinformasjonen, det lisensnøkkelavhengige, brukerspesifikke tjenesteabonnementet ved å benytte klientkrypteringsnøkkel (322 clikey) til signering av senere henvendelser til tjenesteleverandøren som angår det brukerspesifikke tjenesteabonnementet.

2. Arrangement ifølge krav 1, viderekarakterisert vedat tjeneren er anordnet til å registrere terminalen og klienten (100) for den bruker-spesifikke tjenesten og at klienten (100) ved mottak av feilkode ved bruk av tjenesten, videre er anordnet til å overføre fra terminalen til tjeneren (103) en forespørsel om tjenesteaktivering der en terminal-spesifikk identiteten (320) og den bruker-identiteten (321) oppgis i forespørselen, og å signere denne forespørselen av klienten med klientkrypteirngsnøkkelen (322 clikey), at tjeneren (103) er anordnet til å kontrollere at forespørselen fra klienten (100) er signert med klient-krypteringsnøkkel (322 clikey), og dersom forespørselen er korrekt gjennomføres lisens-aktivering og dersom forespørselen er signert feil behandles forespørselen som en anonym henvendelse som beskrevet i punkt 1, at tjeneren (103) er anordnet til å foreta lisens aktivering ved å be brukeren om å akseptere tjenestevilkår og oppgi betalingsinformasjon, og at tjeneren (103) er videre anordnet til å oversende betalingsinformasjon til kredittkort-selskap (104), ved aksept overføres oppdatert lisensinformasjon til klienten (100) og AAA-database oppdateres, og ved avslag avvises forespørselen.

3. Arrangement ifølge krav 2,karakterisert ved at det lisensnøkkelavhengige, brukerspesifikke tjenesteabonnementet tilveiebringer er Mobil-IP-tjeneste, og at feilkoden er feilmelding 131 fra en Mobil-IP-hjemmeagent (101) i henhold til Mobil-IP-standarden definert i IETF RFC3344.

4. Arrangement ifølge kravl, viderekarakterisert ved at klienten (100) også er anordnet til å overføre til tjeneren informasjon som omfatter klientmodell/-versjonsnummer, terminaloperativsystemtype og operativsystem- versjon, foretrukket språk og årsak for forespørselen om aktivering.

5. Arrangement ifølge kravl, viderekarakterisert vedat tjeneren (103) er anordnet til å kreve fra klienten at det også oppgis en gyldig emailadresse eller et gyldig mobilterminalnummer som senere kan benyttes til å kontakte kunden.

6. Arrangement ifølge kravl, viderekarakterisert vedat tjeneren (103) er anordnet til å overføre til en tillatelse til klienten (100) for reinstallasjon ved utstedelse av en kopi av konfigurasjonsinformasjon når forespørselen om aktivering inneholder en for tjeneren kjent terminal spesifikk identitet (320) og brukeren oppgir et brukernavn (321) som eksisterer hos tjeneren fra før.

7. Arrangement ifølge kravl, viderekarakterisert vedat tjeneren er anordnet til å tillate lisens-overføring ved utstedelse av en ny signert konfigurasjonsinformasjon når forespørselen om aktivering inneholder en ny terminalspesifikk identitet (320) og brukeren oppgir et brukernavn (321) som eksisterer hos tjeneren fra før.

8. Arrangement ifølge krav7, viderekarakterisert vedat tjeneren er anordnet til å tillate gjentatt lisens-overføring kun et forutbestemt antall ganger ved å sette en sperre for antall lisens-overføringer som er tillatt per registrerte brukernavn (321).

9. Arrangement ifølge kravl, viderekarakterisert vedat tjeneren (103) er anordnet til å blokkere for utstedelse av konfigurasjonsinformasjon når forespørselen om aktivering inneholder en for tjeneren kjent terminalspesifikk identitet (320) og brukeren oppgir et for tjeneren nytt brukernavn (321).

10. Arrangement ifølge kravl, viderekarakterisert vedat klienten (100) er anordnet til å detektere at det er registrert en terminalspesifikk identitet som ikke har gyldig lisens, og å tilby brukeren automatisk opprettelse av konfigurasjon og lisens.

11. Arrangement ifølge kravl, viderekarakterisert vedat klienten (100) er anordnet til å detektere at versjon av konfigurasjonsdata i klienten ikke stemmer overens med klientprogramvareversjon, og å tilby brukeren automatisk oppdatering av konfigurasjonsinformasjon til riktig versjon.

12. Arrangement ifølge kravl, viderekarakterisert vedat klienten (100) er anordnet til å detektere at det ikke er mulig å nå hjemmeagenten (101) og å redirigere brukeren til en webside som tilbyr assistanse til konfigurasjon.

13. Arrangement ifølge kravl, viderekarakterisert vedat tjeneren (103) er anordnet til å utstede en "leverandørdel" for en tredjepart som kan gi denne tredjepart anledning til å utstede lisenser for aktivering av lisensnøkkelavhengige, brukerspesifikke tjenesteabonnement, uten at denne tredjepart får adgang til å endre tjenesteleverandør og nettadresse for konfigurasjon.

14. Arrangement ifølge kravl, viderekarakterisert vedat tjeneren (103) er anordnet til å utstede en "leverandørdel" for tredjepart som kan gi denne tredjepart anledning til å utstede signerte profiler, uten at denne tredjepart får adgang til å utstede lisenser for klientprogramvare.

15. Arrangement ifølge kravl, viderekarakterisert vedat tjeneren er anordnet til å signere konfigurasjonen som overføres fra tjeneren (103) til klienten (100) for å unngå feilaktig konfigurasjon og tjenestenektangrep mot klienten.