NO20190041A1

NO20190041A1 - System for å reagere på en alarm

Info

Publication number: NO20190041A1
Application number: NO20190041A
Authority: NO
Inventors: Jan Møller
Original assignee: Rescue Consult As
Priority date: 2018-08-01
Filing date: 2019-01-11
Publication date: 2020-02-07
Also published as: NO344930B1

Description

BAKGRUNN

Teknisk område

[0001] Den foreliggende oppfinnelsen gjelder et system for å reagere på en alarm, hvor systemet har en brukerterminal i stand til å sende en alarmmelding til en systemserver.

Kjent teknikk

[0002] ‘Sikkerhet’ omfatter ‘personsikkerhet’ og ‘informasjonssikkerhet’. For eksempel vil en hjelpesentral hjelpe en eldre person som har falt på gulvet hjemme så raskt som mulig, men ønsker ikke å overvåke den eldre personen kontinuerlig av hensyn til privatlivets fred. Hjelpesentralen løser dette ved å utstyre brukeren med en ‘trygghetsalarm’ til å henge rundt halsen. Trygghetsalarmen har en fysisk trykknapp og en funksjon for å sende et alarmsignat til en hjelpesentralslik at han eller hun kan varsle ved behov, i dette eksempelet etter et fall. Hjelpesentralen overvåker ellers ikke personen. Det er generelt viktig å hindre at uvedkommende får tilgang til sensitive data, for eksempel boligadresser til hjelpesentralens brukere.

[0003] I et voldsalarmsystem kan en person utstyres med en lignende alarmenhet. I dette eksempelet er det ikke ønskelig å registrere hvor brukeren befinner seg til enhver tid, kun hvor han eller hun befinner seg når alarmen utløses. I volds- og ransalarmsystemer er det et generelt behov for en skjult utløser som gjør det vanskelig å oppdage at en alarm blir utløst.

[0004] Ansatte i visse organisasjoner kan bli utsatt for trusler fra frustrerte klienter, og ansatte med tilgang til penger eller rusmidler kan bli utsatt for ransforsøk. I banklokaler dekkes behovet for skjult utløser tradisjonelt av en alarmknapp skjult under en bordplate eller lignende. En slik alarmknapp mangler i de fleste andre lokaler. En ansatt på reise eller oppdrag kan også bli utsatt for trusler eller ransforsøk, og følgelig ha behov for å utløse en alarm som i eksempelet med en generell voldsalarm.

[0005] Det er et generelt behov for et system med en bruker som kan utløse en alarm, respondenter som bistår brukeren i en alarmsituasjon og en sentral. Sentralen kan representere en ansatts foresatte i organisasjonen. I dette dokumentet er ‘system’ det samme som ‘informasjonssystem’, og brukeren, respondenten og sentralen er roller i et system for å reagere på en alarm.

[0006] Respondenten representerer en gruppe med en eller flere personer, for eksempel en hjemmehjelp, kolleger som kan bistå en ansatt på kontoret eller på reise, vektere osv.

[0007] En hjelpe- eller vaktsentral koordinerer ressurser og varsler respondenter nær brukeren for å yte raskest mulig hjelp. Sentralen kontakter også eksterne ressurser ved behov, for eksempel ambulanse eller politi. En overordnet ansatt i en organisasjon med potensielt truende klienter har en lignende funksjon. Hjelpesentralen og vaktsentralen kan representeres av en organisasjon med ansatte.

[0008] Et system for å reagere på en alarm inneholder en databaseapplikasjon med rollen ‘bruker’. En tilsvarende bruker finnes i alle systemer der en person logger seg på med brukernavn og passord. Av hensyn til lesbarhet skiller vi ikke strengt mellom person og rolle i det følgende

[0009] US-2008/0284587 beskriver et system for å håndtere personlig sikkerhet, hvor en mobil brukerterminal initierer og sender et alarmsignal til et nettverk i en nødsituasjon.

[0010] US-2008/0189162 A1 beskriver et web- og telefonbasert krisehåndteringssystem med integrerte prosesser, kommunikasjonsinnretninger og -tjenester, samt en bedriftsdatabase med relevant informasjon. Systemet betjener en organisasjons første respondenter, krisehåndteringsteam og andre interne og eksterne interessenter.

[0011] Et generelt klient-server system har en server og en klient som bruker tjenester fra hvert sitt operativsystem til å motta en melding fra et nettverk, lagre filer på disk, osv. Laget over operativsystemet kalles et ‘applikasjonslag’, og meldinger mellom en server og en klient i applikasjonslaget overføres i et tilsvarende applikasjonslag på et nettverk. Dette kan være SMS-meldinger over et mobilnett eller epostmeldinger over internett.

[0012] En webserver på en sentral datamaskin ligger i applikasjonslaget, og en nettleser på en PC er en klient i samme applikasjonslag. En databaseapplikasjon på den sentrale maskinen kan utveksle data med webserveren slik at en bruker eller databaseadministrator har tilgang til databasen gjennom et webgrensesnitt i en nettleser. Noen klient-server systemer har egne klientapplikasjoner som virker på samme måte som en nettleser. En person kan kommunisere med systemet gjennom et grafisk brukergrensesnitt (GUI) med skjermknapper, menyer og felt for å legge inn data. Ulike klient-server systemer har ulike kombinasjoner av GUI i nettleser, GUI i en egen ‘app’, skjermbilder fra serveren mot internett gjennom et webgrensesnitt og mot store skjermer i et kontrollrom gjennom et lokalt grensesnitt.

[0013] Vi bruker her og i det følgende ordet ‘server’ i betydningen ‘tjenesteyter’, ikke i betydningen ‘sentral datamaskin’. En ‘systemklient’ er programvare i applikasjonslaget, ikke en person. Vi kaller sistnevnte ‘potensiell aggressor’ for å unngå eventuelle misforståelser. En ‘terminal’ er et endepunkt i et nettverk, ikke en innretning med stor skjerm i sentralen. For korthet bruker vi uttrykkene ‘data på nett’ for ‘data i i applikasjonslaget’ og ‘data på disk’ for ‘data i en database eller fil i et filsystem’. ‘Brukerdata’ er data tilknyttet en bruker.

[0014] En personlig datamaskin eller PC (‘personal computer’) er i det følgende en datamaskin med en personlig OS-bruker. Dette omfatter en smarttelefon, et nettbrett og andre mobile eller stasjonære datamaskiner. Av hensyn til lesbarhet og forståelse bruker vi begrepene om hverandre, men fellestrekket er ‘personlig’.

[0015] Trygghetsalarmen i et tidligere eksempel er en terminal i et nettverk, og i tillegg en brukerterminal fordi den er personlig. En smarttelefon har en unik IP-adresse i internett og et unikt telefonnummer i et telenett, inkludert mobiltelefonnett. Den er en terminal i flere nett, og en brukerterminal hvis den er personlig for en bruker i systemet for å reagere på en alarm. Den sentrale datamaskinen er en terminal i internett fordi den har en unik IP-adresse. I et informasjonssystem med et telenett, kan en person identifiseres med et personlig telefonnummer, f eks et mobilnummer, og kontrollrommet med et sentralbordnummer.

[0016] En brukerterminal har egenskaper som er typisk for den aktuelle enheten. For eksempel kan brukeren ringe og sende SMS fra en mobiltelefon eller smarttelefon, men telefonen har ikke nødvendigvis en klientapplikasjon med et GUI. En PC har et enbruker operativsystem og et filsystem, og vanligvis en nettleser. En smarttelefon har begrenset batterikapasitet og liten skjerm, og derfor et annet operativsystem, nettleser og webgrensesnitt enn tilsvarende programvare i en PC på kontoret. En smarttelefon kan finne sine GPS-koordinater, og sende dem med SMS eller epost til en systemserver, osv.

[0017] I tillegg til de generelle trekkene ovenfor, har systemet som foreslås her en bruker med brukerdata, nærmere bestemt lyd- bilde- og posisjonsdata på nett eller disk. ‘Data på nett’ er meldinger, samtaler, videostrømmer osv som overføres gjennom et tele- eller datanett. ‘Data på disk’ er data i en database eller fil. Data på ‘nett og disk’ betyr i dette dokumentet det samme som ‘data i sanntid og ettertid’.

[0018] En bruker er her en person som kan utløse en alarm, og organisasjonen kan ha behov for å oppbevare en lydfil med samtalen for senere dokumentasjon, for eksempel for å avklare hva som ble sagt av brukeren og personell i kontrollrommet etter en utløst alarm.

[0019] Tilsvarende kan organisasjonen ønske å dokumentere en uønsket hendelse etter at en ansatt har utløst en alarm. ‘Autorisasjon’ har sammenheng med ‘behov for å vite’, og personer i kontrollrommet kan ha en annen autorisasjon enn en saksbehandler. En gruppe personer har ikke behov for å vite hva som skjer i et fortrolig møte, men blir ‘autorisert for’ et videoopptak hvis det skjer noe dramatisk eller hvis brukeren utløser en alarm.

[0020] Som i andre alarmsystemer er det et generelt behov for å avstille en falsk alarm. I organisasjonens adgangskontrollsystem gjøres dette ved at personen som utilsiktet utløste alarmen ringer en vaktsentral og oppgir et kodeord. I et digitalt system oppgir personen et passord eller lignende.

[0021] En ansatt på reise vil gjerne ha hjelp fra kolleger så snart som mulig hvis hun utløser en alarm, men vil ikke overvåkes kontinuerlig. For eksempel kan GPS-data fra brukerens og kollegenes smarttelefoner vise de ansattes posisjoner, og et digitalt system kan sende en melding til kolleger i nærheten slik at brukeren får hjelp så raskt som mulig. De ansatte mistenker imidlertid at en nysgjerrig person i et kontrollrom har uautorisert tilgang til posisjonene deres i sanntid eller ettertid, og skrur derfor av GPS-lokalisering i perioder både mens de er på oppdrag og mens de er på bytur etter arbeidstid. Det digitale systemet vil i dette eksempelet ikke virke etter hensikten.

[0022] Posisjonsdata eller lokasjoner er ikke begrenset til GPS-data. GPS-data er f eks ubrukelig i et kontorbygg med flere etasjer. Behovet for rask hjelp til en bruker som utløser en alarm i møterommet er som før. I dette eksempelet vet systemet at brukeren er i møterommet, og kan lokalisere kolleger i nærheten ved hjelp av Bluetooth-beacons. Beacons og utstyr med lignende funksjon er handelsvarer som ikke trenger en teknisk forklaring her.

[0023] Personer i kontrollrommet trenger andre skjermbilder og andre funksjoner enn den enkelte bruker, for eksempel en liste over brukere, oversiktskart osv. Et krisehåndteringsteam kan ha behov for å varsle eller sjekke ansatte på reise i et område etter et jordskjelv, en tsunami eller et orkanvarsel, Man vet ikke hva som kan skje, men vet at det er nyttig å vite omtrent hvor ansatte på reise befinner seg for å kunne bistå i tilfelle noe skjer.

[0024] Organisasjoner som beskrevet ovenfor har et generelt behov for å øve på krisesituasjoner i vid forstand. I hjelpesentralen kan formålet være å identifisere mulige forbedringer i kommunikasjon med hjemmehjelper og/eller en ambulansetjeneste under generelle kost/nytte-betingelser. I en annen organisasjon kan formålet være å øve et krisehåndteringsteam slik at alle medlemmene i teamet kjenner sine oppgaver når en uønsket hendelse inntreffer. Siden man ikke kan vite hva som skjer, bør det være mulig å øve på ulike scenarier. Kost/nytte forbyr mange scenarier med virkelige personer i rollene som ‘bruker’, her en person som kan utløse en alarm, en ‘første respondent’ som kommer brukeren til unnsetning osv. I dette eksempelet trengs personer bare til roller i krisehåndteringsteamet.

[0025] Avgrenset til digitale informasjonssystemer, er det et generelt behov for et simuleringssystem som kan generere ulike scenarier for ulike organisasjoner på en kostnadseffektiv måte, spesielt uten personer i alle roller i et scenario.

[0026] Bruker, respondenter, kontrollrom osv. er ‘entiteter’ i et system for å reagere på en alarm. Noen generelle definisjoner og begreper knyttet til miljøet rundt systemet er nyttig før vi fortsetter med beskrivelsen av behov og problemer i alarmsystemet.

[0027] En systemeier i en organisasjon ‘eier’ et informasjonssystem, for eksempel alarmsystemet her eller en annen databaseapplikasjon. Hun er en del av organisasjonen, ikke av det underliggende systemet. Systemeier bestemmer over bruken av systemet, og kjenner alle krav som stilles til systemet, inkludert krav fra organisasjonen og eksterne myndigheter.

[0028] Systemeier i et lokalnett kan sammenlignes med personen Alice, som er systemeier for en eller flere personlige datamaskiner. Alices arbeidsgiver stiller krav om at disker på mobile enheter skal krypteres i tilfelle enheten blir mistet eller stjålet. Personen Alice møter disse kravene ved å kryptere filer og filsystemer i sin smarttelefon og laptop. Et operativsystem i hver maskin har de faktiske funksjonene for kryptering og dekryptering. OSet skjuler kryptografiske nøkler for alle andre enn OS-bruker Alice, slik at bare OS-bruker Alice kan dekryptere filer og filsystemer. Personen Alice er ikke en rolle i et operativsystem.

[0029] De følgende avsnittene gir noen eksempler på eksterne behov, krav og regler som kan bety noe for et system som skal ivareta personvern og digital informasjonssikkerhet [0030] Personvern. EU-direktiv 2016/679 General Data Protection Directive (GDPR) setter krav til forsvarlig oppbevaring av personopplysninger, og er et eksempel på et regionalt regelverk. En organisasjon i et europeisk land kan få bøter for brudd på europeiske regler, inkludert personvernregler.

[0031] Behov for dokumentasjon. Nasjonale helsemyndigheter kan kreve at hjelpesentralen oppbevarer visse opplysninger i en viss tid, typisk noen år. Andre myndigheter kan stille lignende krav til oppbevaring av hensyn til sporbarhet.

[0032] Kommersielle og andre eksterne hensyn. En bedrift vil miste kunder og anseelse hvis publikum mistenker at bedriftens ansatte bruker webkamera i kundenes boliger til kikking. Det er en fordel for bedriften om de ansatte ikke kan mistenkes for å bruke kamera til kikking i sanntid, tyvlytte i lydfiler på disk, osv.

[0033] Intern sikkerhetspolicy. Denne ivaretar hensyn til personvernregler, lover og andre eksterne krav, og legger til sine egne. Organisasjonen har typisk flere graderinger eller nivå av konfidensialitet, men har ikke nødvendigvis et formelt policy-dokument. En rolle klarert for ett nivå kan ‘lese’ informasjon på samme nivå eller lavere. For eksempel har en avdelingssjef ‘tilgang til’ informasjon om ansatte i avdelingen, men de ansatte har ikke tilgang til all informasjon på avdelingsnivå. Systemeier kan forby lyd- og videoopptak av møter på nivå ‘Konfidensiell’, f eks et forretningsmøte, og tillate opptak av møter på nivå ‘Ugradert’.

Autorisasjon, behov for å vite, kommer i tillegg. Avdelingssjefen er ikke autorisert for all fortrolig informasjon bare fordi han er avdelingssjef. Alle Unix- og Windows-lignende systemer følger en matematisk utgave av denne modellen, en ‘Bell-LaPadula’ (BLP) modell. Vi kommer tilbake til dette, men nevner her at en OS-administrator kan ha uautorisert tilgang til en lyd- eller bildefil. Han eller hun kan dermed mistenkes for tyvlytting.

[0034] Kost/nytte. I denne sammenheng spesielt behov for å sikre digital informasjon tilstrekkelig til at uvedkommende ikke får tilgang, og samtidig bruke minst mulig ressurser til å oppnå den nødvendige informasjonssikkerheten.

[0035] Systemeier kjenner de konkrete kravene som stilles, og anvender dem i den grad de betyr noe for et system for å reagere på en alarm. Krav fra organisasjonen og eksterne myndigheter trenger ingen nærmere forklaring her.

[0036] I dette dokumentet bruker vi ‘motstander’ om en trussel mot informasjonssikkerhet, mens en ‘aggressor’ truer personsikkerhet eller eiendom. Informasjonsverdien øker generelt med datamengden. For eksempel er det større sjanser for å finne ‘nyttig’ informasjon i en samling lydfiler på disk enn i én samtale i sanntid. En motstander vil generelt bruke større ressurser til å få tilgang til større datamengder, men det finnes virus og andre skadeprogram som innhenter og/eller endrer informasjon uten hensyn til økonomisk verdi.

[0037] En ‘Mallory’ brukes til å sammenfatte flere av behovene for beskyttelse av informasjon, slik at systemeier bare trenger å forholde seg til én motstander. Mallory kan representere en nysgjerrig person eller hacker, en kriminell gruppe på nett og/eller skadelig programvare. Mistenkt og motiv har ingen betydning i denne sammenheng.

[0038] ‘Sikkerhet’ har aspektene ‘konfidensialitet’, ‘integritet’ og ‘tilgjengelighet’.

Konfidensialitet betyr generelt å hindre uautorisert ‘lesing’ i vid forstand. I telenett brukes begrepet ‘tyvlytting’ av tradisjonelle grunner. Siden alarmsystemet her ligger over et datanett og et telenett, bruker vi ‘lesing’, ‘tyvlytting’ osv om hverandre. Betydningen vil fremgå av sammenhengen. Uautorisert ‘lesing’ innebærer her bruk av programvare for å se innholdet i en lyd- eller bildefil osv uten autorisasjon. Integritet betyr primært å hindre uautorisert endring av data. ‘Uautorisert tilgang’ er det samme som uautorisert lesing og endring av data.

[0039] Innen digital informasjonssikkerhet sikres konfidensialitet med kryptering. En ‘symmetrisk’ nøkkel brukes både til kryptering og dekryptering, og må derfor holdes hemmelig til enhver tid. Et asymmetrisk nøkkelpar består av en privat og en offentlig nøkkel, og har egenskapen at data kryptert med den offentlige nøkkelen bare kan dekrypteres med den private. Asymmetriske nøkler ble utviklet av britiske GCHQ for å redusere kostnader med å beskytte et stort antall symmetriske nøkler i et hovedkvarter, og kostnader for å distribuere symmetriske nøkler med kurer til et stort antall utenriksstasjoner og militære avdelinger.

[0040] Integritet kan tilsvarende sikres med en ‘kryptografisk sjekksum’ kalt et hash. Hashet lages ved bruk av en kryptografisk hashnøkkel, og endres mye hvis innholdet i en melding eller fil endres litt. Det kan være raskere å beregne et hash og sammenligne med et hash fra nett eller disk enn å sammenligne to datamengder byte for byte. Verbet ‘å hashe’ eller ‘hashing’ betyr å beregne en ‘kryptografisk sjekksum’ av en datamengde i en melding eller fil, og deretter ‘lagre’ hashet i en tilhørende melding eller fil.

[0041] Sikre forbindelser på internett, for eksempel til og fra en HTTPS-server, bruker asymmetriske nøkkelpar til kryptering, og hashing for å oppdage om en mann-i-midten endrer data underveis i nettet. Hvis mannen-i-midten blir oppdaget, blir han ‘stoppet’ av mottiltak.

[0042] Sikre forbindelser på internett bruker TLS (‘transport layer security’) i et transportlag under applikasjonslaget. Nøkler brukt til kryptering av disk ligger i et operativsystem under laget med server- og klientapplikasjonene. Moderne operativsystemer bruker hashing og andre teknikker til å stenge ned eller nekte å starte prosesser ved forsøk på modifikasjon. Server og klient i applikasjonslaget har ikke tilgang til nøkler i lag under applikasjonslaget.

[0043] Det er generelt en fordel å bygge inn sikkerhet i designfasen av et digitalt system. For eksempel elimineres behovet for antivirusprogrammer hvis operativsystemet gjør det umulig for virus og andre skadeprogrammer å lese eller endre digitale data.

[0044] Integritet omfatter også ‘autentisering’. Et dokument kan autentiseres med en digital signatur, hvilket krever et personlig sertifikat. I et system med brukernavn og passord, blir en person ‘autentisert’ ved pålogging. Ett-trinns autentisering involverer noe personen kan eller har, f eks et passord eller et magnetkort til å sveipe gjennom en leser. Fler-trinns autentisering involverer noe personen kan og noe personen har, og brukes hvis data i systemet har høy verdi. For eksempel kan en nettbank ha tre-trinns autentisering med et passord, et smartkort og en PIN-kode. En smartkortleser kan kobles til en PC, f eks med en USB-kabel.

[0045] ‘Tilgjengelighet’ betyr generelt at informasjon er tilgjengelig når den trengs. Dette omfatter reserveløsninger, for eksempel reserveutstyr og alternative veier gjennom et nettverk. Slikt utstyr er uten betydning for alarmsystemet her. Sikkerhetskopier av data (‘backup’) kan ha betydning. Backupdata omfatter vanligvis flere generasjoner ‘offsitebackup’, som per definisjon skal oppbevares utenfor driftslokalene i tilfelle noe skjer.

[0046] Sikkerhet må balanseres mot brukerfunksjonalitet, krav fra myndigheter og andre hensyn. I det følgende er sikkerhet relevant når den angår et system for å reagere på en alarm.

[0047] En organisasjon har et ‘sikkert område’ der uvedkommende ikke har adgang, og informasjon på papir og digitale media kan oppbevares og behandles uten risiko for innsyn. I eksempler nedenfor inneholder det sikre området et møterom og kontorene til Alice og Bob. Avgrenset til digital informasjonssikkerhet, er ‘det sikre området’ et lokalnett hvor ansatte kan lagre og behandle dokumenter og andre data i filsystemer avhengig av sine administrative privilegier. Dette forenkler databehandlingen, og er et eksempel på ‘brukerfunksjonalitet’ i vid forstand. Brannmurer og lignende utstyr for å isolere lokalnettet fra offentlige nett er viktig for organisasjonen, men trenger ingen nærmere forklaring her.

[0048] Systemeier må forholde seg til data på nett og disk i og utenfor sikkert område. På internett er TLS sikret mot motstandere med ressurser på statsnivå. Offentlige telenett er i prinsipp sikret mot tyvlyttere med ressurser på statsnivå. Data på disk utenfor sikkert område kan kreve ekstra beskyttelse, for eksempel fordi statlige sikkerhetsmyndigheter kan kreve at en leverandør utleverer kryptografiske nøkler ‘av hensyn til nasjonal sikkerhet’. Hvorvidt dette faktisk skjer har ingen interesse fra et sikkerhetsperspektiv. På et lokalnett har enkeltmeldinger liten verdi. Data på disk i lokalnettet har større informasjonsverdi, og er derfor mer utsatt for angrep fra en motstander, en ‘Mallory i lokalnettet’.

[0049] Organisasjonen behandler konfidensielle papirer ‘forsiktig’ uavhengig av hvilke personer som arbeider eller er på besøk i sikkert område i kontortiden, og uavhengig av skallsikring med låste dører, adgangskort og tilsvarende omkring sikkert område. Konfidensielle papirer kan rutinemessig låses inn i et sikkerhetsskap uten hensyn til hvem en inntrenger er, eller hvordan han kom inn i sikkert område. Det finnes alltid en risiko for sikkerhetsbrudd, f eks at en ansatt glemmer konfidensielle papirer på pulten uten tilsyn.

[0050] I lokalnettet er det tilsvarende behov for å beskytte informasjon uten hensyn til hvilke ansatte eller IT-konsulenter som har tilgang til sentrale datamaskiner, og uten hensyn til brannmurer og lignende. Konfidensiell informasjon beskyttes godt i moderne operativ- og databasesystemer uten hensyn til hvem en motstander er eller hvordan hun kom seg inn i sikkert område. Det finnes alltid en risiko for sikkerhetsbrudd, f eks at noen antivirus- eller andre programmer mangler de siste sikkerhetsoppdateringene, eller at en ansatt klikker på en giftig lenke tross et generelt forbud.

[0051] Skadelig programvare kan smitte fra en flerbrukermaskin til en PC og omvendt, men generelle antivirustiltak hindrer formodentlig omfattende spredning. Vi er spesielt interessert i sentrale maskiner i lokalnettet, og har i mente at brukerne har PCer.

[0052] Anta at Mallory i lokalnettet representerer en uhederlig OS-administrator, en hacker og et skadeprogram. Mallory ønsker å lese og endre alle filer. Hun har rot-tilgang til alle filsystemer i alle sentrale maskiner i lokalnettet fordi en uhederlig administrator eller hacker kan ha hatt eller kan få rot-tilgang til en sentral maskin i fortid eller fremtid. Hun har ferdighetene til en dyktig OS-administrator av samme grunn. Mallory tar hensyn til kost/nytte ved at det er en ekstra kostnad å bryte seg inn i en database eller et ekstra operativsystem i en PC, men hun tar ikke spesielle hensyn til økonomisk verdi. Et spion- eller skadeprogram har ikke nødvendigvis økonomiske motiv. Mallory lar seg stoppe hvis hun blir oppdaget, for eksempel av et oppdatert antivirusprogram eller av mottiltak hvis et beregnet hash ikke stemmer overens med et hash på disk. Mallory blir ikke oppdaget i en systemlogg fordi hun aldri logger seg på.

[0053] Med rot-tilgang mener vi tilgang til toppbruker i et operativsystem og toppnivå i et filsystem. I et Unix-lignende system er dette ‘root’ og ‘/’. Windows-lignende systemer har en tilsvarende toppbruker i operativsystemet og ett eller flere toppnivå i filsystemet. En person med rot-tilgang kan lese og endre alle filer, inkludert systemfiler. I en PC er toppbrukeren i operativsystemet vanligvis skjult for OS-brukeren for å unngå utilsiktet skade.

[0054] BLP-modellen ble opprinnelig publisert i 1973, og er formelt usikker av matematiske grunner. Den er imidlertid ‘brukervennlig’ for de fleste organisasjoner. Nyere operativsystemer er ‘herdet’ mot angrep med andre teknikker, f eks med hashing som beskrevet i et tidligere eksempel. ‘Herdingen’ gjelder imidlertid bare én maskin, og lokalnettet inneholder flere sentrale maskiner. Et moderne databasesystem på organisasjonsnivå bruker som regel andre matematiske modeller enn BLP.

[0055] For eksempel er RBAC, ‘role based access control’, en matematisk modell der ‘role’ har en annen definisjon og funksjon enn en ‘rolle’ med gradering og autorisasjon i en BLP-modell. RBAC og andre sikkerhetsmodeller gjør databasesystemer på organisasjonsnivå generelt mindre sårbare for angrep enn Unix- og Windows-lignende operativ- og filsystemer. Et databasesystem med en nyere sikkerhetsmodell enn BLP kan sammenlignes med et sikkerhetsskap i kontorlokalene. Det kreves ekstra innsats for å bryte seg inn. Databasesystemer som sådan er utenfor omfanget av den foreliggende oppfinnelsen.

[0056] Systemeier tar formodentlig hensyn til kost/nytte, for eksempel prisen for et databasesystem med innebygget sikkerhetsmodell, f eks RBAC, på organisasjonsnivå mot nytteverdien av et pålitelig system for å reagere på en alarm.

[0057] Mallory i lokalnettet kan sammenlignes med en inntrenger i kontorlokalene. Inntrengeren vil vurdere om det er verdt anstrengelsen å bryte seg inn i sikkerhetsskapet eller i låste kontorer der det er liten sannsynlighet for å finne noe han kan ha interesse av.

Inntrengeren blir ikke oppdaget i et adgangskontrollsystem fordi han smetter inn bak en ansatt eller bryter opp en dør, men han kan stanses hvis han blir oppdaget.

[0058] Systemeier har et generelt behov for å sikre mot angrep fra Mallory fordi Mallory representerer flere motstandere uten hensyn til mistenkt og motiv. I dette dokumentet angriper Mallory filsystemer i lokalnettet. Hvis Mallory ikke har tilgang til en fil, så har ikke en virkelig person eller OS-bruker tilgang, uavhengig av hvilke administrative privilegier OS-brukeren har i et filsystem. Mallory fritar implisitt organisasjon og ansatte for mistanke.

Oppsummert har systemeier et behov for å sikre systemet mot Mallory i lokalnettet. Mallory er en angriper utenfor alarmsystemet.

[0059] I alarmsystemet er det behov for å arkivere relevante data, for eksempel et lyd- eller videoopptak av hensyn til dokumentasjon. For alarmsystemet er det uvesentlig om arkivbehovet skyldes en lov, organisasjonens ønske om opptak i tilfelle tilsyn, en saksbehandlers behov for notater eller noe annet. ‘Mistenkt og motiv’ er uvesentlig.

[0060] Det er en fordel å kunne dokumentere tid og sted for opptaket, og at de tilsvarende lyd- eller bildefilene ikke er endret under opphold på disk.

[0061] Relevante data kan ikke avhenge av at en alarm er utløst. En person kan ringe hjelpesentralen og be om hjelp uten å utløse en alarm først. En aggressor kan hindre at en ansatt på møterommet eller på reise får sendt en alarm. En person hjemme, på kontoret eller på reise kan ringe fra en lånt mobiltelefon, så systemet bør kunne identifisere brukeren uten en forhåndsregistrert brukerterminal.

[0062] Mange opptak er uten interesse for ettertiden, og medfører bare kostnader til lagring og sikring. Det er et generelt behov for å slette overflødige data så raskt som mulig.

[0063] Til sammenligning oppbevarer et vanlig CCT-system alle videoopptak en fast periode, for eksempel en måned. Alle opptak slettes eller overskrives straks de er en måned gamle. Dette fyller verken behovet for arkivering eller behovet for rask sletting.

[0064] Det er generelt ønskelig å automatisere arkivering og sletting. Manuell gjennomgang av alle opptak er dyrt. En realistisk serverprosess har en risiko for å slette relevante data for tidlig og overflødige data for sent. Det er ønskelig å redusere denne risikoen.

[0065] Spesielt krever noen personvernregler at visse personopplysninger skal slettes på oppfordring. Hvis irrelevante brukerdata lagres i en sikkerhetskopi, en offsite-backup eller et arkiv, kan det være problematisk å etterkomme dette kravet.

[0066] Aspektet ‘tilgjengelighet’ betyr her at en alarm bør kunne utløses selv om en brukerterminal slås av eller mister evnen til å kommunisere. En applikasjon på en mobil enhet kan bli utilgjengelig selv om det ellers er mulig å kommunisere med enheten. Årsaken er at noen operativsystemer for mobile enheter stenger ned applikasjoner i prioritert rekkefølge ettersom batteriets ladenivå synker under bestemte terskelverdier.

[0067] Formålet med den foreliggende oppfinnelsen er å frembringe et forbedret system for å reagere på en alarm. Systemet skal spesielt ta hensyn til personsikkerhet, personvern og digital informasjonssikkerhet. Generelt skal systemet løse eller redusere minst ett av problemene ovenfor samtidig som trekk og fordeler fra kjent teknikk beholdes.

SAMMENFATNING

[0068] Dette oppnås med et system ifølge krav 1. Foretrukne utførelser er angitt i de uselvstendige kravene. I kravene følger vi konvensjonen at artiklene ‘en’, ‘et’ betyr minst én eller minst ett, mens tallordene én, ett betyr nøyaktig én eller ett.

[0069] Nærmere bestemt gjelder oppfinnelsen et system for å reagere på en alarm, med en systemklient, en systemserver med en database, og en melding mellom systemklienten og systemserveren i et applikasjonslag. Systemet er kjennetegnet ved en systemfunksjon og en reaksjon med minst én systemfunksjon; et mellomlager i et lokalnett med filsystemer hvor systemfunksjoner i systemserveren har lese- og skrivetilgang, og en brukerstatus, hvorav minst én er en alarm-status. Systemet har minst én bruker, hvor hver bruker har et unikt asymmetrisk kryptografisk nøkkelpar med én offentlig nøkkel og én privat nøkkel, samt en personlig gjenstand hvor brukerens private nøkkel er skjult. Systemfunksjonene omfatter en opptaksfunksjon med delfunksjoner for å innhente brukerdata fra en gruppe bestående av lyd-, bilde- , dokument- og posisjonsdata. En krypteringsfunksjon har delfunksjoner for å kryptere og dekryptere en brukers brukerdata med brukerens asymmetriske nøkkelpar. En lagringsfunksjon har delfunksjoner for å lagre brukerdata i databasen eller mellomlageret. Brukerdata kryptert med brukerens offentlige nøkkel kan dermed bare dekrypteres av en krypteringsfunksjon med lesetilgang til brukerens private nøkkel.

[0070] Fra innledningen forstås at meldingen kan være en SMS eller epost, og at både server- og klientsiden har funksjoner eller prosesser for å sende og motta slike meldinger.

[0071] En reaksjon er sammensatt av en eller flere systemfunksjoner, for eksempel Varsling av en eller flere respondenter med en situasjonsbestemt forhåndslagret melding og Markering av bruker på et systemkonsoll.

[0072] Mellomlageret er delmengden av filsystemer i lokalnettet som inneholder ukrypterte og krypterte brukerdata, der systemserveren har lese- og skrivetilgang. Mellomlageret er ikke en egen fysisk enhet. Filsystemene i mellomlageret kan være tilgjengelig i samme maskin som systemserveren eller gjennom en filserver i lokalnettet. Mellomlageret oppbevarer brukerdata i en passende periode, f eks noen dager slik at brukere kan laste ned krypterte filer for notater og personer i et kontrollrom kan merke en fil for arkivering dersom brukeren ikke kan, vil eller tør utløse en alarm. Senere bruker vi ‘fjernlager’ for tilsvarende filsystemer med backupdata utenfor sikkert område.

[0073] Et databasesystem er generelt egnet til å inneholde korte dataelementer som personnavn, boligadresser, filnavn og posisjonsdata. Lengre dataelementer som lyd-, bilde- og dokumentdata kan passe bedre i et filsystem i mellomlageret.

[0074] En brukerstatus i systemet er knyttet til en reaksjon. Systemet kan ha flere alarmstatuser hvor hver alarm-status utløser en alarm-reaksjon. En ansatt på kontoret eller reise krever to forskjellige alarm–reaksjoner avhengig av situasjon.

[0075] Brukerdata omfatter lyd-, bilde-, dokument- og posisjonsdata, Opptaksutstyr for lyd og bilde er henholdsvis en mikrofon og et kamera. Med dokumentdata mener vi filer fra en typisk kontorapplikasjon, f eks et tekstbehandlingsdokument, et regneark osv. Posisjonsdata kan innhentes fra en GPS-funksjon i en smarttelefon, fra Bluetooth-beacons osv.

[0076] Nøklene skal hindre at en uautorisert person kan lese innholdet i en kryptert fil ved hjelp av vanlig programvare. De ‘ligger i applikasjonslaget’. Den personlige gjenstanden kan være en eller flere av brukerens PCer, et smartkort eller en minnepinne med USB-kontakt. Noen minnepinner virker ikke uten brukerens fingeravtrykk. Gjenstander uten elektrisk kontakt til en datamaskin i et nettverk kan ikke leses av Mallory under noen omstendighet. I andre sammenhenger på fagfeltet digital informasjonssikkerhet kalles dette et ‘luftgap’.

[0077] Brukerdata kryptert med brukerens offentlige nøkkel kan bare dekrypteres med den private nøkkelen i nøkkelparet. Krypteringsfunksjonen kan kjøres i en serverapplikasjon og/eller i en klientapplikasjon på en PC eller i en datamaskin på møterommet.

[0078] Systemserveren har tilgang til alle offentlige nøkler. Serverkryptering med en offentlig nøkkel garanterer at ingen uautoriserte personer, her personer uten tilgang til den private nøkkelen i nøkkelparet, kan lese data på disk. Klientkryptering med den offentlig nøkkelen garanterer at uautoriserte, f eks personer i kontrollrommet, verken kan lese data på nett eller disk. Tilsvarende for en OS-administrator. Uten tilgang kan ingen personer mistenkes for tyvlytting.

[0079] Brukeren vil dekryptere etter en ekte alarm, og dermed gjøre filen leselig for en begrenset gruppe autoriserte personer. En uautorisert sjef eller OS-administrator ser ikke innholdet, og er dermed også fritatt for mistanke om tyvlytting.

[0080] Mallory har tilgang til alle nøkler i alle filsystemer i lokalnettet. Hun har ingen nytte av offentlige nøkler fordi de ikke kan dekryptere. Det krever for mye innsats å bryte seg inn i mange PCer, f eks pga stor sannsynlighet for oppdaterte antivirusprogrammer. Systemet er altså sikret mot Mallory såfremt ingen private nøkler ligger i et filsystem i lokalnettet. Det er systemeiers ansvar å påse at ingen lagrer private i lokalnettet av ‘praktiske’ eller andre grunner. Dette kan gjøres med et rutinemessig søk etter systemspesifikke nøkkelnavn.

[0081] Foretrukne utførelser har en hashingfunksjon og en hashnøkkel som kombinerer brukerens private og offentlige nøkkel. Hashnøkkelen bør være unik for brukeren for å dokumentere eierskap til brukerdata. Mallory har tilgang til alle offentlige nøkler og kan forfalske et hash. Hashnøkkelen kan derfor f eks være brukerens private nøkkel kryptert med den offentlige. Ingen uautoriserte kan dekryptere ved bruk av den offentlige nøkkelen, så den private nøkkelen forblir privat mens hashnøkkelen er unik for brukeren. En slik hashnøkkel kan sendes sikkert over nett, men blir offentlig hvis den lagres i et filsystem på lokalnettet.

[0082] I foretrukne utførelser har systemklienten minst én brukermelding, der hver brukermelding i systemklienten tilsvarer en brukerstatus og en reaksjon i systemserveren.

[0083] Noen meldinger, f eks med GPS-data eller lavt batterinivå, kan sendes fra systemklienten uten at en person medvirker. Andre meldinger kan sendes ved hjelp av et GUI. En datamaskin med webkamera på møterommet behøver verken et GUI eller flere meldinger for å kryptere en videostrøm til mellomlageret, men den har fordelaktig en prosess for å motta brukerens offentlige nøkkel til bruk i krypteringen.

[0084] Foretrukne utførelse med en melding sendt fra brukeren har en tilsvarende ‘avslutt’-melding som kansellerer den tilsvarende statusen for brukeren i systemserveren. Dette er spesielt nyttig for å avslutte brukerbestemte perioder. Brukermeldingen kan alternativt inneholde en tidsperiode, og trenger da ingen ‘avslutt’-melding sendt fra systemklienten.

[0085] Noen ‘avslutt’-meldinger krever ekstra autentisering av en person. For eksempel kan avstilling av en ‘falsk’ eller utilsiktet alarm i et digitalt system kreve at brukeren oppgir et passord i et GUI. To-trinns personautentisering bør fortrinnsvis omfatte noe personen har og noe personen kan. En variant brukt i andre systemer er å sende en engangskode med SMS til en persons mobiltelefon, og kreve at personen oppgir engangskoden i et GUI. Alarmsystemet her kan benytte denne og andre kjente teknikker for fler-trinns personautentisering.

[0086] I foretrukne utførelser er en av brukermeldingene en ‘forsinket alarm’- melding med en forsinkelsesperiode. Systemserverens reaksjon utføres ved utløpet av forsinkelsesperioden med mindre brukeren endrer tidspunkt for utførelse av en tilhørende reaksjon.

[0087] Foretrukne utførelser har en brukersendt opptaks-melding, der reaksjonen er å aktivere opptaksfunksjonen for opptaksutstyr nær brukeren. Et opptak av en telefonsamtale krever ingen forutgående melding. Brukerutløst opptak sikrer mot utilbørlig overvåking, og ivaretar dermed brukerens personvern. Brukeren kan avslutte opptaksperioden ved hjelp av systemklientens GUI, f eks med en skjermknapp ‘avslutt’ eller tilsvarende. En brukerstyrt opptaksperiode reduserer mengden av overflødige data på disk.

[0088] Foretrukne utførelser har en brukersendt standby-melding som fører til forhøyet oppmerksomhet fra systemserveren. Dette reduserer responstiden i tilfelle Alarm.

[0089] Forsinkelsesperioden, standby-perioden og opptaksperioden er tre separate perioder som kan, men ikke må, overlappe.

[0090] Foretrukne utførelser har videre en status for brukerdata som overstyrer en automatisk slettefunksjon for data på disk. Denne statusen kan være ‘Arkiveres’ eller ‘Til senere bruk’ og gjelder brukerdata, ikke bruker. Brukerdata uten en slik status kan slettes etter en periode i mellomlageret eller databasen, f eks etter noen dager. Denne perioden gir en person i kontrollrommet anledning til å arkivere brukerdata uten forhåndssendt alarmmelding.

[0091] I foretrukne utførelser kan kansellering av noen systemfunksjoner kreve ekstra autentisering av personen som anmoder om kansellering. Dette kan innebære at Alice må logge seg inn med passord for å avstille en alarm eller slette en videofil fra disk, det er ikke alltid nok at hun har en brukerterminal.

[0092] I noen utførelser har systemserveren en funksjon for å sammenholde lokasjonsdata i en forhåndsbestemt sekvens med faktiske posisjonsdata mottatt fra systemklienten. Sekvensen kan representere en planlagt reise, et oppdrag eller en kveldstur, og den kan inneholde tidspunkt eller tidsintervaller. Avvik kan for eksempel utløse standby- tilstand og en melding til brukeren om å bekrefte at alt er OK. Manglende svar kan her utløse en alarmtilstand som beskrevet for utførelser med tidsforsinkelse. Dette øker personsikkerheten til Alice på reise.

[0093] Foretrukne utførelser har en systemlogg med tidspunkt for når brukerdata opprettes, leses, endres eller slettes, og en brukerID som identifiserer personen som utførte handlingen. Selv om Mallory kan omgå systemloggen, kan den være nyttig for Control eller systemeier. Hensikten er å knytte en person til en handling og en mulig sanksjon. For eksempel kan arbeidsgiver sanksjonere en ansatt ved uautorisert lesing av en ukryptert fil i mellomlageret. BrukerID bør følgelig identifisere en person, ikke en gruppe personer med adgang til en felles administrator-rolle.

[0094] Foretrukne utførelser har en rutine for automatisk sikkerhetskopiering av data i mellomlageret. Dette kan være en del av organisasjonens ordinære backuprutiner. Hensikten er å redusere risikoen ved prematur sletting av brukerdata. Hvis data blir slettet ved en feil, kan de hentes tilbake fra en offsite-backup, som kan være flere måneder gammel. Krypterte brukerdata sikrer konfidensialitet og personvern også i backupdata.

[0095] Systemet her kan videre omfatte en scenarioliste med meldinger fra en produksjonsversjon av systemet og tider for sending av meldingene, samt et GUI med mulighet for å velge en scenarioliste. En eller flere scenariolister med meldinger spiller rollene til fysiske personer i en simuleringsversjon. En Spillmester bruker et GUI til å velge en scenarioliste.

KORT BESKRIVELSE AV TEGNINGENE

[0096] I den følgende detaljerte beskrivelsen beskrives oppfinnelsen ved hjelp av eksempler og med henvisning til tegningene, hvor:

Fig. 1 er en oversikt over et system i samsvar med oppfinnelsen;

Fig. 2 illustrerer systemfunksjoner og reaksjoner;

Fig. 3 er en mer detaljert oversikt over komponenter i systemet;

Fig. 4 illustrerer systemets plassering i ulike protokollstakker;

Fig. 5 er et forenklet ER-diagram med noen entiteter og relasjoner i systemet;

Fig. 6 illustrerer en skjult utløser og en endelig tilstandsmaskin;

Fig. 7 illustrerer interne prosesser, signaler og kanaler; og

Fig. 8 er et forenklet sekvensdiagram med objektorientert dynamikk.

DETALJERT BESKRIVELSE AV FORETRUKNE UTFØRELSESFORMER

[0097] De vedføyde tegningene er skjematiske, og ikke i skala. Detaljer kjent for fagfolk på området er utelatt av hensyn til klarhet i illustrasjonene.

[0098] Fig. 1 illustrerer et system 100 ifølge oppfinnelsen. Et rektangel markerer systemgrensen. Grafiske brukergrensesnitt (GUIer) på en systemklient 220 og et konsoll 140 gjør det mulig for personer representert ved Alice, Bob og Charlie å kommunisere med systemet 100. Et GUI har skjermknapper, menyer og felt til å taste inn data, og trenger ingen detaljert forklaring her.

[0099] Alice representer en bruker i systemet, dvs en person som kan utløse en alarm.

Personen Alice kan ha en eller flere personlige datamaskiner, f eks en smarttelefon, en laptop og en kontor-PC. Det er unødvendig å gjenta eksempler på personlige datamaskiner i hvert eksempel, så vi bruker som nevnt forkortelsen ‘PC’ – ‘personal computer’ - til å representere en stasjonær eller bærbar datamaskin, et nettbrett, en smarttelefon og andre datamaskiner med en personlig OS-bruker. Av hensyn til lesbarhet bruker vi betegnelsene om hverandre.

[0100] Ellipsen 201 markerer utstyr som er nær personen Alice på et gitt tidspunkt. Alice trenger en PC, f eks en smarttelefon 210, i nærheten for å sende en Alarm-melding 202 fra et møterom. Hennes kontor-PC er relevant i andre sammenhenger.

[0101] Alice kan bruke et GUI i systemklienten 220 til å sende Alarm-meldingen 202 til en systemserver 120. Systemserveren 120 kan da sette en Alarm-status 120 på bruker Alice 200 i en database 121. Fig. 2 illustrerer at en Alarm-status 102 utløser en Alarm-reaksjon 162 med én eller flere systemfunksjoner. En av systemfunksjonene er Varsling(liste, melding) 172, som sender en melding til alle personer i listen. Prosesser i systemserveren 120 kommuniserer seg imellom på interne kanaler med interne signaler. Innholdet i ‘liste’ og ‘melding’ vedlikeholdes av en eller flere serveprosesser. I dette eksempelet inneholder ‘liste’ mobilnumrene til Bob og andre av Alices kolleger, og Alarm-meldingen 202 er en SMS med ‘Alarm, Alice, møterom 123’.

[0102] Personen Bob mottar Varslings-meldingen 172, og gir assistanse 20 til kollega Alice i møterom 123. En trussel mot personsikkerhet krever assistanse 20 av en person. Systemserveren 120 sikrer kort responstid, og øker dermed Alices personsikkerhet i forhold til et system der en person er involvert i behandlingen av Alices Alarm-melding 202.

[0103] Bob representerer en gruppe personer med en eller flere medlemmer, for eksempel en hjemmehjelp, kolleger av Alice eller en vekterpatrulje. Bob trenger bare en mobiltelefon, f eks en smarttelefon 210, for å motta en tekstmelding sendt med SMS. Han trenger ikke systemklienten 220 for dette. Bob kan assistere Alice i én situasjon, og Alice kan assistere kollega Bob i en annen. Bobs smarttelefon kan derfor også ha en installert systemklient 220.

[0104] Charlie representerer en gruppe med en eller flere personer i et kontrollrom, f eks i hjelpe- eller vaktsentralen eller kontoret til Control, sjefen til Alice og Bob. Control har myndighet til å kontakte eksterne ressurser, for eksempel ambulanse eller politi. Control har generelt ansvar for flere ansatte, f eks Alice, Bob og/eller Charlier i sentralen. Control og Charlie kan nås gjennom et sentralbordnummer, og personen Control kan ha et mobilnummer.

[0105] Personer og utstyr er eksempler på ‘entiteter’ i systemet 100 for å reagere på en alarm. Entiteter er forbundet med ‘relasjoner’. For eksempel kan en bruker ha en eller flere personlige datamaskiner og en eller flere filer med brukerdata. Fig. 5 er et forenklet ER-diagram som viser noen av entitetene og relasjonene i systemet 100. Systemet 100 har i tillegg systemfunksjoner, f eks for å sende og motta meldinger, for kryptering og hashing osv.

[0106] En simuleringsversjon av systemet 100 omfatter en produksjonsversjon med tillegg av forhåndsbestemte meldinger som sendes til bestemte tider og/eller datamaskinprosesser som spiller rollene til Alice, Bob og/eller Charlie. Simuleringsversjonen bruker meldinger og funksjoner i produksjonsversjonen, slik at det er enkelt å bygge ulike scenarier. For realisme kan en menneskelig ‘spillmester’ påvirke hvilke meldinger som skal sendes avhengig av hvordan spillet utvikler seg. Simuleringsversjonen gjør det mulig å trene grupper av personer, for eksempel brukere, hjelpere, personer i en hjelpesentral eller et krisehåndteringsteam, uten kostnader til virkelige personer Alice, Bob og/eller Charlie for å spille andre roller.

[0107] I et gjennomgående eksempel har et møterom et kamera 231. Før et møte med en potensiell aggressor, aktiverer Alice kameraet 231, slik at det sender brukerdata 250, her en videostrøm, over et lokalnett til systemserveren 120. En Reaksjon 161 på videostrømmen lagrer en bildefil i et mellomlager 130 og filnavnet i en database 121. Dette er bruker Alices fil, så databasen 121 har en relasjon mellom brukeren 200 og en eller flere brukerfiler.

[0108] Hver bruker Alice 200 har et asymmetrisk nøkkelpar privA, pubA, med egenskapen at data kryptert med en offentlig nøkkel pubA bare kan dekrypteres med en privat nøkkel privA i nøkkelparet. Dette er nøkler som brukes til å skjule brukerdata 250 for uautoriserte personer, f eks kollega Bob, Charlie på sentralen og Control. Det er ikke nøkler som brukes til kryptering og hashing på lavere lag, f eks i sikre forbindelse til og fra en HTTPS-server på internett. Data som overføres med TLS er leselig i begge ender av den sikre forbindelsen.

[0109] En systemfunksjon 171 krypterer videostrømmen fra kamera 231 med Alices offentlige nøkkel pubA. Alice holder privA skjult i en personlig gjenstand, f eks i en PC, et personlig smartkort eller en minnepinne med USB-kontakt. Det er dermed bare Alice som kan dekryptere den krypterte videofilen, for eksempel for å ta notater eller for å arkivere en leselig kopi for senere dokumentasjon av en uønsket hendelse.

[0110] Krypteringsfunksjonen 171 kan kjøre i systemserveren 120, systemklienten 220 eller i en datamaskin på møterommet. Alle har lovlig tilgang til Alices offentlige nøkkel pubA. Hvis Alices brukerdata 250 krypteres i møterommet, kan de sendes over lokalnettet uten at en uautorisert Bob, Charlie eller Control kan se dem i sanntid på nett eller i ettertid på disk 130.

[0111] De fleste møter er udramatiske, så Alices brukerdata 250 kan slettes automatisk etter en periode i mellomlageret 130, f eks noen dager. Dette gir Alice tid til å laste ned den krypterte filen til sin kontor-PC i tilfelle hun vil ta notater fra møtet.

[0112] I tilfelle en aggressor hindret Alice i å utløse en Alarm, vil Charlie eller Control høre om hendelsen i etterkant. Alice vil da dekryptere filen slik at en leselig kopi kan arkiveres for senere dokumentasjon. Den dekrypterte filen kan gjøres tilgjengelig for personer som ‘trenger å vite’, f eks Control, som automatisk ble autorisert av den uønskede hendelsen. En OS-administrator er ikke nødvendig for å endre autorisasjon på en leselig fil i et Unix- eller Windows-system i lokalnettet, så innholdet i filen kan holdes skjult også for en uautorisert OS-administrator. Dette kan gjøres på sikker måte med et såkalt ‘luftgap’, dvs uten elektrisk kontakt eller nettforbindelse. En USB minnepinne kan inneholde Alices private nøkkel, og en flyttbar disk kan inneholde den dekrypterte filen.

[0113] I praksis kan Control putte en minnepinne med den dekrypterte filen inn i sin kontor-PC og arkivere den i et fjernlager (400 i Fig. 3) uten at noen OS-administrator på lokalnettet har mulighet til å se den. OS-administratorer har tilgang til sentrale maskiner, f eks filservere, ikke til hver PC i lokalnettet. Den dekrypterte filen trenger ikke lagres i Alices eller Controls PC slik at brukerstøtte eller en hacker som bruker tjenester i brukerstøtteapplikasjonen kan se den. Det er imidlertid lite trolig at en Mallory bryter seg inn i mange PCer i håp om å finne noe av interesse, her Alices dekrypterte videofil, i en av dem.

[0114] Alice senior kan ringe 222 Charlie i hjelpesentralen uten å utløse en alarm først. Til dette trenger hun bare en mobiltelefon 210, ikke nødvendigvis en installert systemklient 220. Charlie på sentralen må nødvendigvis høre samtalen, så det er meningsløst å kryptere på klientsiden i dette eksempelet. På serversiden krypteres 171 samtalen fordelaktig med Charlies offentlige nøkkel pubC før en lydfil med samtalen lagres i mellomlageret 130.

Dermed har uautoriserte personer ikke tilgang til samtalen på disk i ettertid. Charlie vurderer om samtalen har verdi senere, og markerer den i så fall for Arkivering. ‘Arkiveres’ er en status for brukerdata 250, ikke for bruker 200, og kan medføre automatisk kryptering med Alices offentlige nøkkel og/eller hashing med en hashnøkkel som er unik for Alice. Mallory kan forfalske et hash, så pubA er uegnet som hashnøkkel.

[0115] Hashnøkkelen kan i stedet og som eksempel være den private nøkkelen kryptert med den offentlige, dvs privA*pubA automatisk produsert av Alices systemklient 220. Denne nøkkelen kan sendes sikkert over nett fordi ingen andre enn Alice kan dekryptere meldinger kryptert med pubA. Den kan ikke lagres sikkert på disk fordi Mallory kan forfalske et hash med nøkler hun kan lese.

[0116] En database 121 med mange private nøkler kan kreve ekstra beskyttelse og kostnad. Det kan være forsvarlig å lagre Charlies privC i databasen 121 såfremt den beskytter en begrenset mengde brukerdata. Prosesser i systemserveren 120 kan da dekryptere filer automatisk. Datamengden bør begrenses for å redusere skadevirkninger dersom privC blir kompromittert av ukjent årsak. Serverkryptering med Alices pubA motvirker dette.

[0117] Alice på kontoret kan laste ned, dekryptere, og laste opp en fil. Alice senior kan trenge hjelp. Hvis dekryptering sentraliseres, f eks ved at Charlie har en samling minnepinner i en safe på kontoret, så fritas ikke Charlie for uberettiget mistanke om tyvlytting. Tilsvarende hvis en serverprosess kan starte dekryptering i systemklienten 220. Det hjelper ikke med en ‘sikker’ autentiseringen av serverprosessen i systemklienten 220.

[0118] Alice senior vil ikke overvåkes med kamera hjemme. Hun vil ta et bad, og velger en forsinkelsesperiode ‘1 time’ fra en meny i GUIet i systemklienten 220. Systemklienten 220 sender en ‘forsinket alarm’, nærmere bestemt en forhåndsbestemt melding kalt ‘Alarm-T’ i de følgende eksemplene. Systemserveren 120 venter i inntil 1 time før den utløser en alarmreaksjon, f eks med Varsling av hjemmehjelp Bob og Markering av Alice på Charlies konsoll 140. I de fleste tilfeller avstiller Alice senior Alarm-T status før tidsforsinkelsen ‘1 time’ er utløpt. Hun gjør dette ved å aktivere en skjermknapp ‘Avslutt’ i GUIet på systemklienten 220. Et passord er unødvendig for dette.

[0119] En dag klarer ikke Alice senior å komme seg opp av badekaret. Systemserveren 120 utfører da en ‘forsinket alarm’ reaksjon etter1 time. Alarm-reaksjonen starter i dette eksempelet opptak fra en mikrofon 232 i baderommet, slik at Alice kan forklare Charlie på sentralen hva som har hendt. Systemeier bestemmer bruken av systemet 100, og dermed om Charlie på sentralen skal kontakte hjemmehjelp Bob, eller om hjemmehjelp Bob skal varsles automatisk av en prosess i systemserveren 120.

[0120] Systemklienten 220 kan sende en Alarm-T melding til systemserveren 120 om lavt batterinivå uavhengig av personen Alices medvirkning. Hvis Alice er i møterommet, kan systemklienten sende en Alarm-T melding med D = ‘5 minutter’ for å gi henne rimelig tid til å plugge i en lader. Hvis Alice er på reise, kan en annen forsinkelse D (‘delay’) passe bedre.

[0121] ‘Forsinket alarm’ reaksjonen kan avhenge av en underliggende status eller tilstand. I et eksempel blir Alice lokalisert i ‘møterom 123’ i det hun sveiper adgangskortet sitt gjennom en kortleser utenfor døren. Her er ‘lokalisering’ det samme som ‘opptak av posisjonsdata’. Denne handlingen kan også sette Alice i en standby-tilstand med forhøyet oppmerksomhet fra systemserveren 120. Alice er i dette eksempelet i standby-tilstanden i perioden hun er på møterommet. En Alarm-T melding om lavt batterinivå mens Alice er i standby- tilstand kan føre til en melding til Bob: ‘Se hva som skjer på møterom 123’. Når Alice ikke er i standbytilstand, medfører Alarm-T meldingen om lavt batterinivå ingen reaksjon fra systemserveren 120 ved utløpet av forsinkelsesperioden D = ‘5 minutter’.

[0122] En forsinkelsesperiode løser generelt problemer med at utstyr blir utilgjengelig av uspesifisert årsak, f eks lavt batterinivå eller at Alice ikke kan, vil eller tør å utløse en alarm.

[0123] En opptaksperiode der opptaksutstyr sender brukerdata til disk, en standby-periode og en forsinkelsesperiode er tre forskjellige perioder som kan kombineres på ulike måter. For eksempel kan standby-perioden i forrige eksempel sammenfalle med videoopptak fra møterommet i en opptaksperiode. Det forrige eksempelet illustrerer også en grunnleggende byggekloss kalt en ‘tilstandsmaskin’ som brukes til å bygge systemet 100. Dette beskrives nærmere med henvisning til Fig. 6.

[0124] Alice på reise vil også gjerne ha hjelp av kolleger så raskt som mulig. Før reisen legger hun inn en reiserute fra kontor-PCen sin, eksempelvis en sekvens av omtrentlige posisjoner ‘London’, ‘Paris’ og ‘Kuala Lumpur’ med forventede tidspunkt for ankomst og avreise. Dette er korte dataelementer som passer i databasen 121. Posisjonsdata er godt beskyttet i organisasjonens database 121 av grunner nevnt tidligere.

[0125] Kollega Bob og andre ansatte legger inn sine reiseruter når de er på reise. Dermed vet sjefen deres Control eller et krisehåndteringsteam hvem som er på reise i et område, f eks etter et jordskjelv, en tsunami eller en orkan. Hvis Alice er i området der en naturkatastrofe har inntruffet, f eks i Sørøst-Asia eller Amerika, vil Control bruke ressurser på henne, ikke på kollega Bob på reise i Europa. Tilsvarende gjelder et terrorangrep i en by hvis Alice og Bob er i forskjellige byer. Man vet ikke hva som kan skje, men det er greit å kunne agere effektivt hvis noe skjer. Control har for dette formålet et konsoll 140 med stor skjerm og flere skjermbilder og funksjoner i GUIet enn en smarttelefon 210 med en systemklient 220.

[0126] Sjefen til Charlie i hjelpesentralen har et tilsvarende konsoll 140 for å holde oversikt over eldre personers navn og adresser i tilfelle han må ringe etter ambulanse. Responstiden kortes ned hvis systemserveren 120 Markerer Alice senior i et skjermbilde slik at ingen person i hjelpesentralen må finne Alices adresse med et manuelt oppslag.

[0127] Piler 145 til og fra konsollet 140 illustrerer toveis-kommunikasjon med systemserveren 120. Kommunikasjon mellom systemserveren 120 og konsollet 140 kan for eksempel gå gjennom et webgrensesnitt på internett og/eller et grensesnitt på lokalnettet.

[0128] Alice på reise ‘sjekker inn’ i systemet 100 når hun ankommer en by, nærmere bestemt ved å aktivere en skjermknapp i systemklientens 220 GUI. Systemklienten 220 henter en GPS-posisjon med et systemkall i operativsystemet, og sender posisjon og tidspunkt i en melding til systemserveren 220. En prosess 160 i systemserveren 120 mottar meldingen fra systemklienten 220, og fordeler ulike komponenter i meldingen til andre prosesser med interne signaler i interne kanaler. Dette beskrives nærmere med henvisning til Fig. 7.

[0129] Alice på oppdrag tar lydopptak og bilder med smarttelefonen sin og skriver notater på laptopen til bruk i en senere rapport. Hun krypterer filene med brukerdata med sin offentlige nøkkel, nærmere bestemt ved å merke filene i en fil-leser i systemapplikasjonen 220, og velge ‘send kryptert’ eller tilsvarende i GUIet. Alices lydfiler, bildefiler og notater fra reisen blir dermed trygt oppbevart i mellomlageret 130 selv om Alices PC skulle bli mistet eller stjålet. Lyd- eller bildefilene blir lagret en periode i mellomlageret 130 slik at Alice kan dekryptere dem når hun er tilbake på kontoret.

[0130] Alice eller systemklienten 220 kan markere lydfiler, bildefiler og notater med en status ‘til senere bruk’. Denne statusen er forskjellig fra ‘Arkiver’-statusen i et tidligere eksempel, og illustrerer at et dataelement kan ha flere statuser. Det er brukerdata, ikke bruker, som er ‘til senere bruk’, og som ikke skal slettes eller arkiveres av en automatisk prosess.

[0131] Fig. 2 illustrerer at en Reaksjon avhenger av en status og består av en eller flere systemfunksjoner. En Alarm-reaksjon 162 reagerer på en Alarm 102, og inneholder systemfunksjonene Varsling(liste, melding) 172, Markering(Alarm, konsoll) 173, som markerer Alice på Charlies konsoll 140, osv. En Forsinket alarm-reaksjon 163 reagerer på en forsinket alarm-status Alarm-T 103, og venter en forsinkelsesperiode D før den utfører andre systemfunksjoner, f eks Varsling(liste, melding) 172.

[0132] Under forsinkelsesperioden D, venter systemserveren 120 på en valgfri endringsmelding 204 fra brukeren 200. Alice på reise vil på bytur etter endt arbeidstid, og bruker GUIet i systemklienten 220 til å taste inn T = ‘2200’, tidspunktet hun forventer ̈å være tilbake på hotellet. Verken kollega Bob eller Charlie på sentralen trenger å vite hvor hun er. Hun blir forsinket, og sender en endringsmelding 204 med nytt tidspunkt T = ‘2300’. Hun er tilbake på hotellet kl 2230 og avstiller den forsinkede alarmen. For dette må hun oppgi passord.

[0133] Hvis brukermeldingen Alarm-T inneholder en forsinkelsesperiode D, så utløses alarmen ved tidspunkt T = (nå D). Hvis meldingen inneholder et tidspunkt T, vil systemserveren utløse alarmen ved T, og forsinkelsesperioden er implisitt D = (T – nå). Det er likegyldig om Alarm-T meldingen inneholder D eller T såfremt server og klient er enige om hvilket format som brukes.

[0134] En avstilt alarm endrer status på bruker Alice i systemet 100. En systemfunksjon Autentiser(person) kan kreve at Alice oppgir et passord før perioden D avsluttes. En aggressor kan dermed ikke avstille alarmen. I en variant kan Alice taste inn et kodeord, f eks ‘Hjelp’, i stedet for passord og dermed utløse en umiddelbar alarm.

[0135] Alarm-reaksjonen kan i dette eksempelet være å innhente Alices GPS-posisjon og varsle alle kolleger som er på reise med Alice. Man trenger ikke kollegenes eksakte GPS-posisjoner for dette. Den som kommer først frem til Alice assisterer henne. Meldinger sendes ikke til alle Alices kolleger, bare til kollegene på ‘liste’ i en systemfunksjon tilsvarende Varsling(liste, melding) 172 i tidligere eksempler. For Alice på kontoret, kan en serverprosess starte med å identifisere kolleger som er på jobb før den prøver å finne en mer nøyaktig posisjon, f eks kolleger i samme etasje som møterom 123. GPS-data kan byttes med andre posisjonsdata osv. i tilsvarende eksempler.

[0136] Oppsummert kan systemklienten 220 sende en forhåndsbestemt brukermelding, for eksempel for å sette en opptak-, standby eller forsinkelsesperiode. Meldingen kan valgfritt sendes av en person ved hjelp av et GUI i systemklienten 220. Personen/brukeren kan oppgi perioden i brukermeldingen eller avslutte perioden med en ‘Avslutt’ melding. I en Alarm-T-melding er forsinkelsesperioden D eller et ekvivalent tidspunkt T obligatorisk. Periodene kan overlappe som beskrevet ovenfor.

[0137] Fig. 3 viser flere detaljer i systemet 100.

[0138] En stiplet linje 101 illustrerer det sikre området med digitale data under systemeiers kontroll som beskrevet. Det sikre området 101 inneholder en sentral datamaskin 110 som kjører systemserveren 120. Systemserveren 120 har også databasen 121 med opplysninger om Alice, Bob, Charlie og andre entiteter.

[0139] Et databasesystem er generelt best egnet til å inneholde korte dataelementer, for eksempel personnavn, boligadresser, telefonnummer og filnavn. Et filsystem er generelt bedre egnet til å lagre lengre dataelementer, for eksempel en lyd- eller bildefil. Systemserveren 120 har derfor lese- og skrivetilgang 125 til filsystem(er) i et mellomlager 130. Et filsystem i mellomlageret 130 kan ligge på disk i den sentrale datamaskinen 110, eller være tilgjengelig gjennom en filserver i lokalnettet. Databasen 121 inneholder fortrinnsvis bare filnavn, som avhenger av om det lokale filsystemet er Unix-lignende, Windows-lignende eller noe annet.

[0140] GPS-koordinater og andre posisjonsdata kan lagres praktisk i databasen 121 fordi de er korte dataelementer. Det er imidlertid fullt mulig å lagre dem i en fil i mellomlageret 130. Det er tilsvarende mulig å lagre lyd- og bildefiler i databasen 121. I eksemplene her følger vi vanlig praksis, som er å lagre korte dataelementer i databasen 121 og lengre dataelementer i et filsystem. Her er de ‘lengre dataelementene’ brukernes lyd- og bildefiler i mellomlageret 130. Mellomlageret 130 er filsystemer i lokalnettet som inneholder brukerdata og som systemserveren 120 har lese- og skrivetilgang til. Mellomlageret 130 er ikke nødvendigvis en egen fysisk enhet i det sikre området 101.

[0141] Systemserveren 120 er fortrinnsvis en databaseapplikasjon frontet av en HTTPS-server mot internett, slik at systemserveren 120 er tilgjengelig for et konsoll 140 gjennom et sikkert webgrensesnitt. Systemserveren 120 kan i tillegg eller alternativt ha et grensesnitt mot et konsoll 140 på lokalnettet. Konsollet 140 brukes av Charlie på sentralen og Control. Disse kan typisk endre noe av innholdet i databasen 121, f eks opprette, endre og slette en brukerrolle, men ikke endre databasestrukturen, lister med statuser osv.

[0142] En systemadministrator Admin er her en av Controls underordnede i organisasjonen med tilsvarende funksjon som en OS-administrator i et operativsystem eller en databaseadministrator i et databasesystem. Admin tar instruks fra systemets 100 systemeier, og vedlikeholder lister med statuser osv. Han kan for eksempel legge til nye kortlesere utenfor møterom hvis og når de blir tilgjengelige fra adgangskontrollsystemets systemeier. Admin bruker også et konsoll 140, men har andre funksjoner og skjermbilder i GUIet enn Control.

[0143] Nettverket 150 illustrerer et data- eller telenett, f eks internett, et mobilnett eller et lokalnett. En ‘terminal’ er her et endepunkt i nettverket 150. En trygghetsalarm til å henge rundt halsen har en fysisk trykknapp 211 til å sende et alarmsignal til systemserveren 120 og er en terminal. Den er en brukerterminal 210 fordi den er personlig tilknyttet en bruker 200. Andre brukerterminaler 210 er en smarttelefon, et nettbrett, en bærbar datamaskin osv.

Fellestrekket med disse maskinene er som nevnt at de har en personlig OS-bruker.

[0144] Noen brukerterminaler 210 har en installert systemklient 220 med et GUI der brukeren 200 kan sende en forhåndsbestemt melding til systemserveren 120 ved å aktivere en skjermknapp 221. Alice på kontoret kan bruke en skjult skjermknapp 222 til å sende en alarmmelding uten å påkalle oppmerksomhet fra en potensiell aggressor. Hun kan for eksempel berøre eller sveipe over et felt på skjermen som ikke har noen synlige grafiske ikoner. GUIet i systemklienten 220 har i tillegg menyer, felt til å taste inn data osv.

[0145] Den stiplede ellipsen 201 illustrerer som i Fig. 1 brukerterminaler 210 og opptaksutstyr 230 – 232 i nærheten av brukeren 200. Ellipsen 201 illustrerer ikke et kommunikasjonsnett, for eksempel Bluetooth-forbindelser til og fra en smarttelefon.

Opptaksutstyret kan omfatte en spesiallaget enhet 230 med innebygget (‘embedded’) prosessor av typen som brukes til å strømme videosignaler til en TV. En slik enhet eller en annen datamaskin kan kobles til kameraet 231 og/eller mikrofonen 232.

[0146] Kameraet 231 og mikrofonen 232 er ikke nødvendigvis tilknyttet brukeren 200 til enhver tid. Alice og kollega Bob bruker samme møterom til forskjellige tider, og et kamera 231 i møterommet er kilde til forskjellige bildefiler for Alice og Bob i mellomlageret 130. Kameraet 231 er bare relevant for Alice når det strømmer Alices brukerdata, tilsvarende for Bob. I begge tilfeller er kameraet 231 ‘nær’ brukeren 200 i møterommet.

[0147] En datamaskin i møterommet, for eksempel enheten 230, kan motta Alices eller Bobs respektive offentlige nøkler pubA fra systemserveren 120 eller deres respektive brukerterminaler 210 i møterommet, og bruke de offentlige nøklene til å kryptere brukerdata som beskrevet ovenfor. Tilsvarende gjelder lyddata fra en mikrofon, og for opptaksutstyr i en bolig eller andre steder.

[0148] Posisjonsdata, for eksempel GPS-koordinater fra en smarttelefon, er også bare relevante når smarttelefonen er nær brukeren 200. Alice på reise har en laptop på hotellet, men posisjonsdata fra laptopen har ingen spesiell interesse når hensikten med systemet 100 er å skaffe assistanse 20 til Alice på bytur så raskt som mulig. Posisjonsdata fra kollega Bobs smarttelefon er relevante når den er i nærheten av Bob og mottar signaler fra Bluetoothbeacons i kontorbygget.

[0149] Et fjernlager 400 inneholder arkiverte data for senere dokumentasjon og/eller sikkerhetskopier (‘backupdata’). Fjernlageret 400 representerer filsystemer i lokalnettet eller på internett. Som beskrevet tidligere, bør overflødige data slettes fra mellomlageret 130 raskest mulig. Foretrukne utførelser arkiverer brukerdata kryptert med brukerens offentlige nøkkel pubA i fjernlageret 400 automatisk etter utløst alarm. Ved feilutløst alarm forblir dermed brukerens 200 brukerdata 250 uleselige for uvedkommende. Dette imøtekommer krav om forsvarlig oppbevaring av persondata, og personers eiendomsrett til egne data som stilles i enkelte personvernregler.

[0150] Foretrukne utførelser har en rutine for automatisk sikkerhetskopiering av data i mellomlageret 130, for eksempel til fjernlageret 400. Sikkerhetskopieringen kan være en del av organisasjonens ordinære backuprutiner. Hensikten er å redusere risikoen ved prematur sletting av brukerdata 250. Hvis data blir slettet ved en feil, kan de hentes tilbake fra en offsite-backup, som kan være flere måneder gammel. Krypterte brukerdata sikrer konfidensialitet og personvern også i backupdata.

[0151] Store datamengder i et fjernlager 400 på internett kan kreve ekstra beskyttelse. Dette kan gjøres ved å kryptere med den offentlige nøkkelen pubS i et asymmetrisk nøkkelpar [privS, pubS] som tilhører systemserveren 120. Nøkkelen pubS kan fordelaktig være lenger enn de tilsvarende pubA og pubC, tilsvarende for de respektive private nøklene.

[0152] En nasjonal sikkerhetsmyndighet har ressurser til å knekke 1024 bit nøkler, og kan angripe 512 bit nøkler med matematiske metoder. Se f eks https://weakdh.org. En slik motstander kan alternativt og billigere forlange at en leverandør utleverer nøkler ‘av hensyn til nasjonens sikkerhet’. Leverandøren kan i dette eksempelet levere skylagring på internett, et operativsystem med en bakdør ‘i tilfelle OS-brukeren glemmer passordet til sine krypterte disker’ eller være en sertifikatutsteder CA – ‘certificate authority’. Slike leverandører finnes i virkeligheten. Hvorvidt statlige myndigheter presser dem er uten interesse her. En Mallory uten spesifisert ‘mistenkt og motiv’ er vanlig. Sikkerhetsmyndigheter i Kina, Russland eller USA vil av prinsipp ikke stole på en skyleverandør eller CA fra ett av de to andre landene.

[0153] Av disse og lignende grunner er det vanlig å anbefale 4096 bit nøkler for å beskytte produksjonsdata på disk over internett. Kommersiell og ikke-kommersiell programvare for å generere 4096 b nøkkelpar er tilgjengelig online. Tilsvarende kortere nøkler brukes til sikker epost. Programvare med åpen kildekode har fordelen at ingen kommersiell eller statlig aktør kan legge inn bakdører. Et online søk etter ‘sikker epost’ eller standarden ‘OpenPGP’ gir flere detaljer og referanser. Enkelte land har en maksimal tillatt lengde på nøkler, og forbyr enkelte algoritmer ‘av hensyn til nasjonal sikkerhet’. Dette vet systemeier.

[0154] Et vanlig nettsøk og sosiale media illustrerer at det finnes statistiske algoritmer for å identifisere data som er relevante for en spesifikk bruker i en stor mengde data i løpet av få sekunder eller kortere. Slike algoritmer er tilgjengelige for andre aktører på internett med ressurser på statsnivå. Korte sporadiske meldinger med innhold ‘S20022200’ eller lignende er uforståelig for utenforstående, og gir ikke statistisk grunnlag for noen statistisk algoritme. De kan derfor sendes åpent over et mobilnett eller internett uten at en tyvlytter med ressurser på statsnivå kan tolke innholdet. Vi kommer tilbake til dette.

[0155] I systemer med private nøkler i systemspesifikke filer kan systemserveren lagre en hashet privat nøkkel privS der en forhåndsbestemt byte er endret med en eksklusiv-eller med en sikkerhetbyte. For eksempel kan byte nr 383 være 10101010. En eksklusiv-eller (XOR) med en sikkerhetbyte endrer siffer der sikkerhetsbyten har en ‘1’ og endrer ikke ved en ‘0’, så (1010 1010) XOR (11110000) = (01011010). En ny XOR med sikkerhetsbyten returnerer byte nr 383 til sin opprinnelige verdi.

[0156] Anta at Mallory ser en slik privS som ikke kan dekryptere. Bare systemserveren 120 vet at (byte 383) XOR (sikkerhetbyte) må utføres før privS vil virke. Mallory vet ikke hvilken byte som er endret, og sikkerhetsbyten trenger selvsagt ikke være 1111 0000. Et 64 b OS utfører en XOR på 8 byte i én instruksjon, og et hash beskytter mot endring. En slik algoritme er altså et billig vern mot Mallory. Det kan være upraktisk å bruke XOR-algoritmen på brukernes private nøkler fordi den krever ekstra og ikke-standard kode i kommersiell og ikkekommersiell programvare for ende-til-ende beskyttelse mellom server og klient.

[0157] Et hash over brukerdata, brukernavn og et tidsstempel beviser eiendomsrett og opphav til data. I eksempelet med Alices videofil, er det bare Alice som kan reprodusere et hash over en kryptert og arkivert videofil hvis hashnøkkelen er unik for Alice. Nøkkelen kan være privA*pubA som i et tidligere eksempel. Mange hashnøkler i databasen 121 krever ekstra beskyttelse, hvilket kan bli dyrt i forhold til nytteverdien.

[0158] Fig. 4 illustrerer systemserveren 120 som en serverapplikasjon på et operativsystem (OS) i den sentrale datamaskinen 110, og systemklienten 220 som en tilsvarende klientapplikasjon på et OS i en brukerterminal 210. Systemserveren 120 og systemklienten 220 kommuniserer i applikasjonslaget 150. Server- og klientapplikasjonene bruker tjenester fra de underliggende operativsystemene, for eksempel til å lese og skrive data fra og til et filsystem. Systemklienten 220 har en meldingsfunksjon som bruker funksjoner fra underliggende lag, for eksempel til å kryptere, finne maskinens GPS-posisjon eller hente informasjon om batterinivå. Systemklienten kan ha et GUI. Datamaskinen i møterommet kan kryptere, men trenger ikke et GUI.

[0159] Hver datamaskin, i dette eksempelet 110 og 210, kan forenklet beskrives som en stabel med maskinvare (HW) nederst, et operativsystem (OS) over maskinvaren og et applikasjonslag med én eller flere applikasjoner over operativsystemet. Maskinvaren omfatter en prosessor, minne og nettkort for kablet eller trådløs tilkobling til et nettverk. En spesiallaget brukerterminal 210 kan ha en såkalt ‘embedded’ prosessor med svært lite operativsystem og begrenset funksjonalitet, for eksempel akkurat nok til å ringe en hjelpesentral. En smarttelefon har en litt større prosessor konstruert for å bruke minst mulig effekt. En stasjonær PC har vanligvis en enda større og raskere prosessor med flere kjerner, og den sentrale datamaskinen 110 kan være en klynge av flere fysiske maskiner slik at systemserveren 120 ikke går ned selv om en av de fysiske maskinene i klyngen havarerer.

[0160] Bortsett fra spesielle operativsystemer for ‘embedded’ prosessorer, er operativsystemene oftest Unix- eller Windows-lignende systemer tilpasset prosessoren i den enkelte datamaskinen, her 110, 210. Unix-lignende OS har lokale filsystem med toppnivå ‘/’, og Windows-lignende filsystemer system har lokale filsystem med toppnivå C:\, D:\ eller lignende. En lokal filserver fs1 kan presentere en fil som fs1:/dir/filnavn eller FS1\dir\filnavn avhengig av operativsystemet under serverapplikasjonen. Noen organisasjoner bruker NFS-‘Network File System’, og noen organisasjoner bruker virtuelle private nettverk (VPN) i stedet for Ethernett eller WiFi. Det finnes flere andre varianter.

[0161] Det er umulig å gi en fullstendig oversikt over alle kombinasjoner av prosessorer, operativsystemer og filsystemer nå og i fremtiden. Operativ- og filsystemer er av spesiell interesse i systemet 100 fordi systemserveren 120 og systemklienten 220 bør tilpasses de vanligste operativsystemene. I dag kan dette være iOS, OS-X eller Android på enbrukermaskiner og en tilsvarende Linux-variant med flere OS-brukere i den sentrale maskinen 110. Dette er Unix-lignede operativsystemer med tilhørende filsystemer. Windows-lignende operativ- og filsystemer for PCer og den sentrale datamaskinen 110 er også vanlig.

[0162] Et nettverk kan tilsvarende forenklet beskrives som en stabel med maskinvare nederst, en protokollstakk over maskinvaren og et applikasjonslag 150 på toppen. Man tenker seg at kommunikasjon skjer internt i hvert lag. For eksempel kan en PC ha nettkort med kabel til et lokalt Ethernett og/eller et nettkort med radioforbindelse til et WiFi-nett. Disse nettene er på et lavt nivå i stabelen sammen med repeatere, basestasjoner og annet utstyr på offentlige nett. På et høyere lag kan hver datamaskin identifiseres med en IP-adresse, og hver telefon med et telefonnummer. Underliggende utstyr og protokoller er uten betydning for kommunikasjon mellom enheter ved hjelp av IP-adresser eller telefonnummer.

[0163] I TCP/IP-stakken som brukes på internett, definerer TCP (‘transport control protocol’) ‘porter’ på den enkelte IP-adressen, Portene gjør det mulig å definere flere tjenester på samme IP-adresse, for eksempel epost på en port og webtjenester på en annen. TCP forutsetter at det er opprettet forbindelse på IP-laget, og er ellers uavhengig av IP-laget.

[0164] Sikre tjenester på internett, for eksempel en HTTPS-server, sender data til TLS (‘transport layer security’), som krypterer og hasher data før de sendes gjennom transportlaget. I motsatt ende av transportlaget sørger TLS for at dataene dekrypteres og at hashene sjekkes. TLS sender deretter leselige data til applikasjonslaget. Her kan ‘leselige data’ representere en webside og/eller andre strukturerte data, f eks i XML-format, som ikke kan eller skal tolkes av en nettleser. Effekten på applikasjonslaget 150 er uansett at leselige data sendes over en sikker forbindelse. Hva som skjer på transportlaget og lagene under er uinteressant for systemet 100. Hensikten med nøklene i systemet 100 er at data i applikasjonslaget 150 skal være uleselige for uautoriserte personer, i eksemplene her representert ved Bob og Charlie som noen ganger trenger å se Alices data, andre ganger ikke.

[0165] Mer generelt beskriver OSI-modellen en stabel med sju lag som benyttes i offentlige nett, inkludert 3G, 4G og 5G mobilnett. Lag 7 i OSI-modellen kalles ‘applikasjonslaget’, og Fig. 2 viser skjematisk en stabel med OSI-lag 1-6 under applikasjonslaget. Detaljer finnes i lærebøker og online. Et lokalnett har en tilsvarende protokollstakk.

[0166] Det er umulig å gi en utfyllende beskrivelse av utstyr og protokoller på eksisterende og fremtidige nett, spesielt på lag under applikasjonslaget. Dette er heller ikke nødvendig, i det vi presiserer at kommunikasjon i nettverket 150 skjer i applikasjonslaget. Av samme grunn er en mer detaljert beskrivelse av HW og OS-lagene på de enkelte datamaskinene unødvendig her. Applikasjonslaget 150 i Fig. 2 er uformelt, og ligger over både internett (TCP/IP), et offentlig telefonnett og et lokalnett.

[0167] TLS motstår Mallory med ressurser på statsnivå, så manglende sikkerhet i transportlaget er ikke et problem. De asymmetriske nøklene i systemet 100 krypterer fra ende-til-ende i applikasjonslaget 150 for å hindre innsyn fra uautoriserte personer. Nøkler og programvare følger fortrinnsvis en åpen standard, f eks OpenPGP. Epost på internett, SMTP, mangler en sikker variant som bruker TLS. Ende-til-ende nøkler brukes også til sikker epost. En rekke kommersielle og ikke-kommersielle programvarepakker er tilgjengelig online.

[0168] Nøkler på applikasjonslaget krever ingen pålitelig CA. Til sammenligning inneholder alle maskiner på internett sertifikater med nøkler utstedt av operativsystemleverandøren til bruk i TLS.

[0169] Figur 4 viser bare et lite utvalg av protokollstakker for å illustrere prinsippet med et applikasjonslag. Det finnes tilsvarende ‘stabler’ for lokalnett, filsystemer osv. For systemet 100 er det særlig relevant at en opptaksfunksjon i applikasjonslaget kan bruke delfunksjoner i et underliggende lag til å innhente lyd-, bilde- og posisjonsdata. ‘Posisjonsdata’ kan videre deles inn i data fra en GPS-funksjon eller Bluetooth-funksjon i en smarttelefon. Det finnes flere mulige alternative teknikker for å finne en posisjon eller lokasjon, f eks NFC, RFID osv.

[0170] Alice kan som nevnt lokaliseres i møterommet i det hun sveiper adgangskortet sitt gjennom en kortleser utenfor døren. Dette krever tillatelse fra adgangskontrollsystemets systemeier, og kan samtidig autentisere personen Alice i systemet 100. Med disse forutsetningene kan systemserveren 120 sende Alices offentlige nøkkel pubA til datamaskinen i møterommet gjennom et WiFi-nett, og starte et videopptak. Datamaskinen i møterommet krypterer videoopptaket med pubA før videostrømmen lagres som en kryptert fil i mellomlageret 130. Alice trenger ikke å ha med seg sin smarttelefon eller laptop i møtet. Det finnes mange kombinasjonsmuligheter.

[0171] Fig. 5 er et forenklet ER-diagram med noen entiteter og relasjoner i systemet 100. Databasen 121 kan være, men må ikke være, en relasjonsdatabase (RDB). Vi bruker en RDB som eksempel her fordi en entitet enkelt lar seg illustrere med en tabell i en RDB. Et system for å håndtere en database, for eksempel et RDBMS, er utenfor omfanget av den foreliggende oppfinnelsen, dvs uten interesse i system 100. Kråkefot betyr ‘en eller flere’, og stiplet stilk betyr ‘kan ha’.

[0172] En Person 301 har i dette eksempelet attributtene ‘Navn’ og ‘Nummer’. Asterisk ‘*’ foran Navn betyr at dette attributtet er obligatorisk. Et databasehåndteringssystem, f eks et RDBMS håndhever regelen slik at ingen får opprettet en Person 301 uten Navn.

[0173] I en RDB tilsvarer entiteten Person 301 en tabell 311 med en kolonne der alle radene har et Navn, og noen har et Nummer. En potensiell aggressor, A. Gressor, mangler mobilnummer i tabell 311. Et RDBMS tilordner en unik brukerID for hvert navn. BrukerID er illustrert med et siffer i kolonnen lengst til venstre i tabellen 311.

[0174] Tabellen Person 311 kan tenkes å ha en kolonne ‘Status’ der mange av radene er tomme, og de radene som har en verdi har én av verdiene fra listen i Status 303. Relasjonen mellom Person 301 og Status 303 er imidlertid et mange-til-mange forhold siden hver Person 301 kan ha flere statuser, og hver Status 303 kan tilordnes flere personer. Vi forklarer nærmere i beskrivelsen av oppløsningen 306 mellom en person P og en rolle R.

[0175] En Person 301 kan sende en brukermelding 302 for å sette en brukerstatus 303 i databasen 121. Systemet 100 har meldinger til Bob som er sendt fra systemserveren 120, og som altså ikke er meldinger fra Person Alice til systemserveren 120. Brukermeldinger 302 og brukerstatuser 303 er delmengder av systemets meldinger og statuser. En konvensjon av mulig nytte er å bruke lignende navn på brukermeldinger, statuser og reaksjoner som hører sammen. Med denne konvensjonen gir en Alarm-melding en Alarm-status, en Alarm-T melding en Alarm-T status, en Standby-melding en Standby-status, osv. Videre har hver status en Reaksjon med samme prefiks, Alarm, Alarm-T osv. Systemserveren 120 har som vist i Fig. 2 en reaksjon med en eller flere systemfunksjoner for hver status.

[0176] Systemet 100 har en relativt kort liste over mulige brukerstatuser, og en tilsvarende kort liste over forhåndsbestemte brukermeldinger som bør lagres i systemklienten 220. Hver brukerstatus har en statusID. I dette eksempelet har en Alarm statusID S1, og en tidsforsinket alarm Alarm-T har statusID S2. En forsinket alarm utløser en reaksjon fra systemserveren 120 ved et tidspunkt T ved utløpet av en forsinkelsesperiode som beskrevet ovenfor. Den sporadiske meldingen ‘S20022200’ tolkes i dette eksempelet av systemserveren 120 som en S2 = Alarm-T sendt av brukerID 002, Alice A. Tacked, med T = kl 2200, tidspunktet Alice på bytur regner med å være tilbake på hotellet. Systemserveren 120 er ikke avhengig av Alices mobilnummer for å finne brukerID 002, og alle Alices PCer kan inneholde hennes brukerID.

[0177] Brukermeldinger for å utløse en alarm, starte en forsinket alarm, en standby-periode og en opptaksperiode med tilsvarende brukerstatuser og en ‘Avslutt’-melding er beskrevet ovenfor. Vi gjentar ikke beskrivelsen her, men understreker at en brukermelding setter brukeren 200 i stand til å sette status selv. Videre kan systemserveren 120 sette en alarmstatus på brukeren 200 uten at brukeren 200 har sendt en alarm-melding.

[0178] Entiteten Utstyr 304 inneholder opplysninger om maskinvare som er relevant i systemet 100. Dette kan være et systemkonsoll140, en brukerterminal 210 og/eller opptaksutstyr 230 – 232. Kråkefot med stiplet stilk betyr ‘kan ha en eller flere’.

[0179] Systemkonsollet 140 trengs for å vise Charlie en oversikt over flere brukere 200, for eksempel en kort liste over brukere med Standby-status. En Person 301 kan ha ett eller flere systemkonsoller 140, f eks med et webgrensesnitt mot internett og/eller et grensesnitt mot lokalnettet.

[0180] Hver Person 301 kan også ha en eller flere brukerterminaler 210, og en eller flere gjenstander 230 – 232 for å innhente lyd-, bilde- og posisjonsdata.

[0181] En brukerterminal 210 i et telenett har et permanent telefonnummer. En brukerterminal 210 på internett har en IP-adresse som kan endres fra oppkobling til oppkobling eller som kan være gjemt bak IP-adressen til en WiFi-ruter. Hensikten med applikasjonslaget over TCP/IP er å skjule slike detaljer for applikasjoner som systemet 100. Brukerterminalen UT (‘user terminal’) er derfor knyttet til en brukerID som i venstre kolonne i tabell 311, ikke til en maskinadresse. Tilsvarende gjelder en spesiallaget enhet 230, et kamera 231, en mikrofon 232, og i et lokalnett med en protokollstakk forskjellig fra TCP/IP.

[0182] Entiteten Rolle 305 er en kort liste over roller en person eller gruppe av personer kan ha i systemet 100. Charlie eller Control kan velge Rolle for en Person fra en meny av Roller. Admin oppretter og vedlikeholder listen av Roller 305 etter instruks fra systemeier.

[0183] Charlie representerer en gruppe personer, og har et sentralbordnummer. I tidligere eksempler har Alice rollen R1 = bruker, definert som en person som kan utløse en alarm. Bob har hatt rollen R2 = ‘hjelper’ i betydningen ‘første respondent’ eller ‘assistent’ for Alice i nød. Charlie har hatt rollen R3 til en hjelpe- eller vaktsentral, og R4 er en valgfri aggressor-rolle.

[0184] Alice kan ha rolle R1 i en situasjon og hjelpe kollega Bob i en annen. Kollega Bob kan ha rollen R2 som i tidligere eksempler, men kan være brukeren med rolle R1 i en annen situasjon. Generelt kan en Person 301 ha en eller flere roller 305, og en rolle 305 kan tildeles en eller flere Personer 301. Entiteten P/R 306 med tilhørende kråkeføtter løser opp mange-tilmange forholdet mellom Person P og Rolle R.

[0185] Tabell 316 illustrerer entiteten 306 i en RDB-tabell 316 med overskriften ‘P R’. I første datarad knyttes brukerID 1, Alice Aged, til rollen R1 = bruker. De neste radene knytter brukerID 2, Alice A. Tacked, til roller som bruker R1 og hjelper R2. Tabellen 316 kan sorteres etter brukerID P og gi en liste over hvilke roller R en Person 301 har. Alternativt kan tabellen 316 sorteres etter rolle R, og gi en liste over Personer 301 som har rolle R1, R2 osv.

[0186] Generelt kan en oppløsning av et mange-til-mange-forhold gi lister som kan vises i et GUI på systemkonsollet 140. For eksempel kan et webgrensesnitt med et GUI vise brukeren Alice A. i en rad i en liste over brukere i Standby-status, og markere raden for Alice A. med blinkende rød skrift idet Alice A. settes i Alarm-status. Charlie på sentralen trenger ikke overvåke alle brukere like nøye, og reagerer umiddelbart på Alices alarm-status. Dette reduserer Charlies responstid, og forbedrer Alices personsikkerhet. Systemserveren 120 kan i tillegg sende en Varsling-melding til Bob og andre kolleger nær Alice uten å vente på Charlie. Som vist i Fig. 2, omfatter en Reaksjon i systemserveren 120 en eller flere systemfunksjoner, f eks Varsling av Bob og Markering av Alice på systemkonsollet 140.

[0187] Fig. 5 er et eksempel med noen få entiteter. En litt større utgave kunne vist at en bruker 200 kan ha en eller flere filer, hver med en filstatus ‘kryptert’, ‘arkivert’ osv. Videre kan hver Person 301 ha en eller flere lokasjoner, hvorav noen kan representere en reiserute. Et virkelig ER-diagram kan selvsagt også ha flere elementer i listene, for eksempel en arkivarrolle for en person som gjennomgår ukrypterte filer i mellomlageret 130 og markerer filer som skal arkiveres. Et detaljert ER-diagram med tilhørende systemregler og -funksjoner må overlates til fagmannen som kjenner det konkrete bruksområdet for systemet 100.

[0188] Fig. 6 illustrerer en skjult utløser 240 og en tilstandsmaskin. Hensikten med skjulte utløsere er generelt å hindre at en aggressor oppdager at brukeren 200 utløser en alarm.

Skjulte utløsere er generelt overflødige i et system 100 laget for en hjelpesentral. En forsinket alarm, Alarm-T i eksemplene ovenfor, reduserer også behovet for skjulte utløsere.

[0189] Fig. 6 viser spesielt en uskyldig gjenstand 241 på et bord 24 i et møterom. Gjenstanden 241 inneholder en permanentmagnet 242 med et tilhørende magnetfelt 243. En spole eller Halldetektor 244 detekterer magnetfeltet 243. Når gjenstanden 241 flyttes på bordet 24, induseres en strøm i spolen 244. Dette fører til at et elektrisk styresignal, f eks i området mA og mV eller lavere, føres gjennom en linje 245 til basen i en transistor 246, slik at transistoren 246 begynner å lede fra kollektor til emitter Dermed går en drivstrøm, f eks 5 V likestrøm, gjennom en elektrisk krets 247 med en sender 248. Senderen 248 kan representere et nettkort i en datamaskin, en egen innretning 230 med ‘embedded’ prosessor eller annen kjent teknikk for å sende data som beskrevet ovenfor. Hvis senderen 248 har en strømforsyning med innebygget transformator, kan transistoren 246 byttes ut med et rele eller en tyristor, og strømkilden 249 være et vanlig forsyningsnett med 240 V vekselstrøm.

[0190] I systemet 100 kan gjenstanden 241 assosieres midlertidig med Alice og/eller Bob. Gitt at brukeren 200 har Standby-status som beskrevet, vil en aggressor neppe reagere på at en uskyldig gjenstand 241 skyves til side av Alice eller Bob. Man kan også tenke seg skjulte utløsere 240 basert på annen kjent teknikk, f eks RFID eller talestyring der et kodeord utløser alarmen. Teknikken avhenger av hva som er tilgjengelig, for eksempel pålitelig talestyring.

[0191] Standby-status er her en forutsetning for at en alarm-melding skal være gyldig: Det må være mulig å rydde bordet 24 uten å utløse en alarm. En ‘(endelig) tilstandsmaskin’ kan generelt beskrives med en liste over ‘stimuli’ og et (endelig) antall ‘aksjoner’ per stimulus. Tabell 1 viser utdrag av en slik liste.

Tabell 1: Eksempel på tilstandsmaskin i listeformat

[0192] Utdraget i tabell 1 dekker både gjenstanden 241 i Fig. 6, et tidligere eksempel der Alice på kontoret lokaliserte seg selv ved å sveipe adgangskortet sitt og et eksempel der Alice på bytur bruker et GUI til å sette en standby-status.

[0193] Et system, inkludert systemet 100, kan generelt beskrives som en ‘agent’ bestående av en blokk med en eller flere prosesser. Agenten’ utfører en eller flere ‘(re)aksjoner’, og kan inneholde andre blokker med andre prosesser. Systemserveren 120 i Fig. 1 er en slik blokk/agent. Agenten på laveste nivå i denne modellen er en tilstandsmaskin.

[0194] Det er mulig å kjenne igjen trekk fra UML, nærmere bestemt en bruksmodell i Fig. 1 og et ER-diagram i Fig. 5. Fig. 8 er et uformelt sekvensdiagram. Dette dokumentet er ikke et systemdesign, og vi bruker ikke formelle spesifikasjoner eller diagrammer. Poenget her er at det finnes flere ‘syn’ på et system, og at en systemdesigner kan bruke et standardisert verktøy, ikke nødvendigvis et UML-verktøy, til å bygge et virkelig system 100.

[0195] Fig. 7 illustrerer en mottaker-prosess 160 nevnt i tidligere eksempler med grafiske elementer som brukes i design av telekom-systemer og maskiner med innebygget prosessor. Åpen pil fra venstre til prosessen 160 betyr ‘asynkron’, dvs at meldingen kan ankomme på et hvilket som helst tidspunkt. En sort prikk i enden av pilen betyr ‘ekstern’ i betydningen ‘fra en kilde utenfor diagrammet’. Systemserveren 120, systemklienten 220 og datamaskinen 230 på møterommet kan ha en slik mottaker-prosess 160.

[0196] Prosessen 160 kommuniserer med andre prosesser gjennom interne kanaler 701 ved hjelp av signaler eller meldinger 702. Nærmere bestemt fordeler prosessen 160 oppgaver til andre prosesser 703, 704, 705 avhengig av mottatt melding, status på bruker og brukerdata, type brukerdata osv. I systemserveren 120 kan prosessene 703-705 implementere en eller flere reaksjoner 161, 162, 163 og/eller systemfunksjoner; 171, 172, 173 nevnt ovenfor, eller prosessene 703 – 705 kan representere helt andre serverprosesser.

[0197] I denne beskrivelsen og patentkravene betyr ‘meldinger’ det samme som ‘eksterne meldinger’ i applikasjonslaget mellom server og klient. Vi vil bruke ‘signaler’ om ‘interne meldinger’ 702. Hver interne kanal 701 har en ‘forsinkelse’ som er uten interesse her, og som ikke skal forveksles med forsinkelsesperioden i en Alarm-T melding beskrevet tidligere.

[0198] Fig. 8 er et uformelt sekvensdiagram der åpen pil med prikk betyr det samme som i Fig. 7. Rektangler med tekst i første rad representerer ‘objekter’ i betydningen ‘ting med data og metoder for å håndtere seg selv og egne data’. En Mottaker 160 representerer en prosess i systemserveren 120, systemklienten 220 eller datamaskinen 230 som i Fig. 7.

[0199] En Bruker 200 er her et ‘objekt’, og ikke det samme som en rolle i ER-diagrammet i Fig. 5. Objektet i Fig 8 kan ha interne brukerstatuser ‘Alarm’, ‘Alarm-T’, ‘Opptak’ og ‘Standby’ hentet fra en kort liste i databasen 121 og tidligere eksempler. Objektet 200 i Fig. 8 har i tillegg metoder for å opprette, endre, og slette en brukerstatus etter en ‘stimulus’ eller et internt signal 702.

[0200] En Brukerfil 250 representerer brukerdata 250 på nett og disk pluss metoder for å opprette, endre og slette egne datastatuser som ‘Arkiver’, ‘Til senere bruk’ osv. Det har andre dataelementer eller ‘attributter’, og i utgangspunktet metoder for å opprette, endre og slette attributter.

[0201] Et Objekt 800 er et generelt objekt med attributter og metoder. Attributtene er ikke de samme som i ER-diagrammet i Fig. 5, og objekter 800 har som regel flere metoder enn de som trengs for å opprette, endre og slette attributter. Objektorientert design og programmering gjør det mulig å endre data og metoder i et objekt uten at det påvirker andre deler av systemet. Til sammenligning er store monolittiske programmer med rutiner og subrutiner lite fleksible og vanskelige å vedlikeholde. Det vil bli klart at systemfunksjonene 171 – 173, og følgelig reaksjonene 161 – 163, nevnt tidligere kan realiseres med objekter.

[0202] Notasjonen ‘en Mottaker’ 160, ‘en Bruker’ 200 osv. er valgt for å illustrere at objektene er forskjellig fra entitetene i Fig. 5 og prosessene i Fig. 7. I en virkelig utførelse er objektene 160, 200, 250 og 800 i Fig. 8 instanser av respektive klasser med fellestrekk. En systemdesigner vet hvordan et virkelig sekvensdiagram for et OO-system bygges opp, at objektene i Fig. 8 kan erstattes med andre objekter, og at flytdiagram er bedre egnet til å illustrere algoritmer med forgreninger og løkker. Dette er utenfor omfanget av oppfinnelsen.

[0203] En vertikal stiplet linje under hvert objekt representerer ‘levetid’ for objektet, og rektangler langs de stiplede linjene illustrerer når objektet er ‘aktivt’, f eks i minnet til den underliggende datamaskinen 110, 210 osv. Horisontale piler representerer signaler, dvs.

‘interne meldinger’ 702. Disse avhenger av andre prosesser i diagrammet, er ‘synkrone’ og representeres med fylte piler. Stiplede piler representerer returmeldinger.

[0204] Spesifikt illustrerer Fig. 8 en asynkron Melding til en mottaker fra en kilde utenfor diagrammet. Som nevnt, kan diagrammet representere objekter i en av flere datamaskiner.

[0205] Meldingen kan implisere at brukerdata 250 skal krypteres og lagres. En mottaker 160 spør 801 en Bruker 200 etter den offentlige nøkkelen pubA. Objektet ‘en Bruker’ 200 kan ha pubA lagret i et attributt, en metode for å finne pubA eller lignende. Det vesentlige for en Mottaker 160 er at den kan anmode en Bruker 200 om en nøkkel, og få den tilsendt i en returmelding.

[0206] Objektet ‘en Mottaker’ 160 henvender seg deretter til objektet ‘en Brukerfil’ 250 med signalet 802: ‘Krypter med pubA og lagre’. Objekter har konseptet ‘meg’ eller tilsvarende, så ‘en Brukerfil’ 250 sender signalet 803 ‘Krypter meg’ og deretter 804 ‘Lagre meg’ til ‘et Objekt’ 800. Signalene 803, 804 får hver sine kvitteringer, og ‘en Brukerfil’ 250 kvitterer tilbake til ‘en Mottaker’ 160.

[0207] Meldingen til ‘en Mottaker’ 160 kan alternativt eller i tillegg implisere at brukerdata 250 skal hashes og arkiveres. En metode i ‘en Bruker’ 200 returnerer privA*pubA etter anmodning 805 fra ‘en Mottaker’ 160. En videre anmodning 806 sendes til ‘en Brukerfil’ 250, som kvitterer når jobben er gjort. Meldingen 806 kan betraktes som input eller stimulus til en ‘agent’ som utfører handlingene 807 ‘Hash meg’ og 808 ‘Arkiver meg’. Som nevnt fins det flere ‘syn’ på systemet 100 som utfyller hverandre, og er nyttige for hver sine formål. Et ‘syn’ er her det samme som ‘view’ i et representativt engelskspråklig design- eller modellverktøy.

[0208] Et vesentlig poeng her, er at objekter 800 i systemet 100 kan sikres med hashing og stenging av prosesser på tilsvarende måte som systemfiler og prosesser sikres i et moderne OS. Databasen 121 trenger kun å inneholde brukernavn, filnavn osv. som nevnt tidligere. Den trenger ikke sikres ytterligere med databasespesifikk RBAC eller andre teknikker. Dette reduserer systemeiers kostnader og opprettholder hennes nytteverdi.

[0209] Posisjonsdata har generelt kort levetid og dermed begrenset behov for kryptering og hashing. De kan derfor vanligvis lagres ‘åpent’ i en ordinær database, men de kan selvsagt krypteres og hashes som andre brukerdata hvis systemeier ønsker det.

[0210] En systemlogg i systemet 100 inneholder fortrinnsvis en brukerID og tidspunkt for hvem som opprettet, endret eller slettet brukerdata i systemet. BrukerID bør knyttes til person, ikke til en felles administrator-rolle. Det er dermed generelt mulig å identifisere hvem som har gjort hva, og hindre uønsket adferd med en mulig sanksjon fra arbeidsgiver. I eksempelet med forbud mot opptak i møterommet, kan Control eller systemeier finne ut hvem som tok opp video av et forretningsmøte (opprettet data). Videre detaljer overlates til systemdesigner.

[0211] For enkel referanse lister vi systemfunksjoner nevnt ovenfor:

Tabell 2: Eksempler på systemfunksjoner

[0212] Det forstås at systemfunksjonene i Tabell 2 og andre systemfunksjoner i systemet 100 fordelaktig kan realiseres med objekter som vist i Fig. 8 for å lette senere vedlikehold av programvare og tilpasning til ny teknikk etter hvert som den blir tilgjengelig. Vi avslutter med noen eksempler der vi bruker konvensjonen med argumenter i parentes bak funksjonsnavnet.

Eksempel 1: Bolig- og kontoralarm

[0213] Alice har et boligalarmsystem med et webkamera. Hun har ‘standby-status’ mens hun er ute av huset. I standby-perioden kan bevegelsessensorer, ‘skjulte utløsere’, starte webkameraet og sende en videostrøm til vaktsentralen. Utenfor standby-perioden virker ikke webkameraet. Alice kan avstille en falsk alarm med et kodeord, ‘Autentisering(person)’, som i andre alarmsystemer for en bolig eller et kontorbygg. Systemfunksjoner Opptak og Kryptering i en systemklient 220 kan kryptere en videostrøm slik at Charlie på sentralen ikke kan se innholdet. Etter et ekte innbrudd, kan Alice laste ned den krypterte videofilen, dekryptere og laste opp en leselig utgave i et vanlig webgrensesnitt med https://-adresse. TLS i transportlaget hasher, krypterer osv uten at det påvirker Alice og Charlie. Charlie kan nå lese innholdet i filen med vanlig programvare.

Eksempel 2: Umiddelbar alarm

[0214] Alice på kontoret eller reise setter en ‘standby-status’ via et GUI på en av hennes PCer, fortrinnsvis en smarttelefon hun har med seg. Smarttelefonen kan identifiseres fra sitt mobilnummer eller fordi systemklienten 220 sender Alices brukerID = 002 i Standbymeldingen til systemserveren 120. Standby-meldingen(e) kan også inneholde GPS-koordinater, ‘møterom nr 123’ og annen informasjon som kan korte ned responstiden fra Bob eller Charlie. Alices lokasjons- eller posisjonsdata kan lagres i databasen 121 uten at noe menneske behøver å se dem. I det Alice sender en Alarm, har systemserveren 120 alle opplysninger som trengs for å varsle Bob og andre kolleger i nærheten med én melding, Alices sjef Control med en annen melding og eventuelt markere Alice i systemkonsollet 140. Charlie er i dette eksempelet prosesser i systemserveren 120, ikke en fysisk person.

Eksempel 3: Tidsforsinket alarm

[0215] Alices systemklient har en forhåndslagret Alarm-T melding og en adresse til systemserveren (120), f eks et telefonnummer for en SMS-melding og/eller en epostadresse. Brukermeldingen Alarm-T om tidsforsinket alarm krever et tidspunkt T for når systemserveren 120 skal utføre en alarm-reaksjon. Alice hjemme velger en forhåndsinnstilt forsinkelsesperiode 1 time fra en meny, T = nå 1 time. Alice på reise taster inn T = ‘2200’, tidspunktet hun regner med å være tilbake på hotellet. Alice kan bruke GUIet til å legge inn relevant informasjon om hvor hun skal osv. Alices GPS-posisjon eller at Alice er i møterom 123 kan innhentes uten at personen Alice bruker GUIet, for eksempel ved at systemklienten 220 innhenter GPS-data og sender en melding automatisk. Meldinger med relevante posisjoner lagres i databasen 121 uten at noe menneske behøver å se dem.

[0216] Før tidspunkt T kan Alice forlenge Alarm-T perioden med en ny Alarm-T eller avstille Alarm-T med en Avslutt-melding. Avstilling kan kreve Autentisering(person), og sletter alle data forbundet med Alarm-T, typisk posisjonsdata i databasen 121. Ved tidspunkt T utfører system-serveren en forhåndsbestemt alarm-reaksjon uavhengig av om Alices PC er tilgjengelig eller ikke. Systemserveren har da alle opplysninger som trengs for å varsle Bob og Control som ovenfor. Charlie er igjen fortrinnsvis prosesser i systemserveren 120.

Eksempel 4: Reiseplan med avsjekk

[0217] Alice oppretter en reiseplan der destinasjon, forventet ankomsttid og informasjon om reisen legges inn. Alices foresatte, Control, vil ha nytte av denne informasjonen hvis det hender noe i området Alice befinner seg i eller har oppgitt som reisemål.

[0218] Når Alice legger ut på reisen, vil hun kunne aktivere automatisk avsjekk med ønsket intervall. Meldingen kan legges inn via GUIet med menyvalg og/eller inntasting av intervall på samme måte som i Alarm-T-meldingen ovenfor. Alice på reise kan i tillegg velge å sjekke inn manuelt med kommentarer osv. Noen kommentarer kan sendes som krypterte lyd- eller bildefiler med opptak fra Alices smarttelefon.

[0219] Avsjekking sender en GPS-posisjon til systemserveren 120, hvor den lagres uten at noe menneske behøver å se den. Alice kan bevisst deaktivere GPS-sporing gjennom GUIet. Alices foresatte, Control, kan likevel proaktivt og uten tidstap avkrefte eller bekrefte om Alice har vært utsatt for uønskede hendelser fordi han har tilgang til planlagt reiserute og Alices omtrentlige posisjon.

[0220] De fleste reiser forløper uten uønskede hendelser, så systemserveren 120 kan slette data fra reisen automatisk etter et passende opphold i databasen 121 og/eller mellomlageret 130. Alice kan for eksempel ha nytte av lyd- eller bildedata fra reisen. Alice kan selv slette data som beskrevet ovenfor. Alice har ofte tilgang til konfidensiell informasjon, for eksempel om potensielle aggressorer, som personene Bob, Charlie og Control ikke er autorisert for.

Eksempel 5: Trusler i kontorlokalene

[0221] En utførelsesform er ment for bruk i lokaler der en potensiell aggressor kan true ansatte, publikum eller eiendom. Systemserveren 120 kan brukes til å varsle internt så vel som eksternt. Organisasjonen kan begrense myndighet til å kontakte politiet eller andre eksterne ressurser, i dette eksempelet til Control. Systemserveren 120 (‘Charlie’) sjekker i dette eksempelet hvem av Alices kolleger som er på jobb før det gjøres forsøk på a finne Bob med Bluetooth-beacons. Som nevnt vil ikke GPS gi en korrekt posisjon i et kontorbygg med flere etasjer. Det er generelt ønskelig at en person lokaliseres i kontorbygget uten å registrere seg manuelt, f eks gjennom et GUI i systemklienten.

[0222] Det er Admins oppgave, ikke Controls, å legge inn nye kortlesere utenfor møterom hvis og når de blir tilgjengelige fra adgangskontrollsystemet. Admin vedlikeholder også lister over statuser, hvilke attributter som er obligatorisk og annen generell systeminformasjon. Alice, Charlie og Control har typisk ansvar for innholdet i systemet 100, og kan for eksempel ha administrative privilegier til å opprette en ny Person 301 med obligatorisk navn. Hvis databasen 121 er en relasjonsdatabase, er det et RDBMS som nekter Alice eller Control å registrere en bruker uten navn. I en RDB er det også et RDBMS som nekter uautoriserte personer tilgang til Alices posisjons- eller lokasjonsdata.

[0223] Alice kan aktivere en skjermknapp ‘opptak’ før hun møter en potensiell aggressor i møterommet. Systemserveren 120 setter i dette eksempelet automatisk standby-status på Alice, og vet hun er i møterommet uten at Alice trenger å bruke GUIet til å oppgi hvor hun er. Som nevnt kan pubA til en Kryptering på datamaskinen i møterommet komme fra systemklienten 220 eller systemserveren 120. Systemserveren 120 kan varsle Bob på nabokontoret om å være ekstra oppmerksom.

[0224] De fleste møter forløper uten hendelser, og Alice avslutter opptaket. Dette avslutter også standby-perioden. Standby-perioden begrenser mengden av overflødige data på disk. Den krypterte videofilen fra Alices møte kan slettes etter et kort opphold på disk. Det samme gjelder opplysninger i databasen 121 om når Alice var i møterommet.

[0225] Organisasjonens sikkerhetspolicy kan forby videoopptak av visse møter i rommet, f eks forretningsmøter. Hvis ‘opptak’ startes ved en feil, inneholder systemloggen informasjon om hvem som startet opptaket og følgelig hvem som har den private nøkkelen til dekryptering..

[0226] I noen møter slutter aggressoren å være potensiell, og Alice utløser en alarm. Da sender systemserveren en ny melding til Bob, som reagerer raskt fordi han er varslet på forhånd. I fall aggressor hindrer Alice å utløse alarm, kommer ikke Bob til unnsetning.

Charlie hører likevel om hendelsen i etterkant, og arkiverer videofilen fra møtet.

Eksempel 6: Alarmkontroll

[0227] Et typisk hierarki har systemeier på toppen. Hun bestemmer hvordan systemet skal brukes, og gir de nødvendige instrukser til Admin og Control. Control kan typisk velge mellom alternative måter å bli underrettet på. For eksempel kan det være praktisk å få opp et skjermbilde på kontor-PCen i én situasjon, og å motta en SMS i en annen.

[0228] I en foretrukket utførelse er Charlie en eller flere prosesser i systemserveren 120 som tar imot alarmer fra systemklienten 220 eller andre serverprosesser, for eksempel ved utløpet av en tidsforsinket alarm. En rolle i organisasjonen, systemeier og/eller Control, bestemmer hvem som skal varsles når og med hvilken melding, eventuell markering på systemkonsoll 140, osv. De ønskede reaksjonene lagres i systemserveren 120. Systemet 100 avhenger ikke av at en fysisk person holder hodet kaldt i en nødssituasjon. Forhåndsdefinerte reaksjoner utføres automatisk av systemserveren 120.

Eksempel 7: Reisekontroll

[0229] Control har oversikt over personer på reise i en ‘ReiseKontroll’. Dette er en delmengde av serverapplikasjonen med en egnet mengde skjermbilder og systemfunksjoner. I ReiseKontroll kan Control se hvor den enkelte brukeren er, brukerens reisemål og andre data brukeren har gjort tilgjengelig. Control kan søke etter brukere som har sjekket inn på en bestemt lokasjon eller som har lokasjonen som reisemål. Dette muliggjør Varsling av brukere som befinner seg i et område. Skjermbildene kan som tidligere gjøres tilgjengelig gjennom et webgrensesnitt og/eller gjennom et systemkonsoll 140 i lokalnettet.

[0230] Et systemkonsoll 140 med stor skjerm gir som regel mer informasjon og bedre oversikt enn en typisk smarttelefon-applikasjon. For eksempel kan en stor skjerm vise større deler av et kart med leselige navn enn en liten skjerm. Et større systemkonsoll gir også lettere tilgang til systemfunksjoner med tilhørende argumenter enn en applikasjon for en smarttelefon. På en stor skjerm er det lett å ringe inn alle brukere i et større område, f eks etter et jordskjelv, en tsunami eller et orkanvarsel. Man vet ikke på forhånd hva som kan skje, men ønsker å varsle eller sjekke hvis noe skjer. Til sammenligning kan systemserveren 120 automatisk varsle alle tre kolleger som er på reise sammen med Alice når Alice utløser en alarm. Den som kommer først frem hjelper Alice. Til dette trenger systemserveren 120 ingen GPS-informasjon fra kollegene, men den kan trenge en liste med mobilnumrene til kollegene som er på reise med Alice og en SMS-melding som Control har skrevet på forhånd.

Eksempel 8: Simuleringl

Organisasjonen vil trene et administrativt team, som i dette eksempelet inneholder personen Control. En simuleringsversjon av systemet 100 har lister med forhåndsbestemte meldinger og tidspunkt for når de skal sendes. Meldingene er hentet fra en virkelig utførelse av systemet 100, en produksjonsversjon Listene spiller i dette eksempelet rollene til Alice og Bob, og utgjør delscenarier. En Spillmester bruker et konsoll 140 med et GUI for å holde oversikt over spillets gang, og velger delscenarier etter hvert som spillet utvikler seg.

[0231] Systemet 100 er beskrevet ved hjelp av eksempler som kan modifiseres uten oppfinnerisk innsats. Omfanget av oppfinnelsen er definert i de etterfølgende patentkravene.

Claims

Patentkrav

1. System (100) for å reagere på en alarm, med en systemklient (220), en systemserver (120) med en database (121), og en melding mellom systemklienten (220) og systemserveren (120) i et applikasjonslag (150),

karakterisert ved

- en systemfunksjon og en reaksjon med minst én systemfunksjon;

- et mellomlager (130) i et lokalnett med filsystemer hvor systemfunksjoner i systemserveren (220) har lese- og skrivetilgang,

- en brukerstatus, hvorav minst én er en alarm-status,

- minst én bruker, hvor hver bruker har et unikt asymmetrisk kryptografisk nøkkelpar med én offentlig nøkkel og én privat nøkkel, samt en personlig gjenstand hvor brukerens (200) private nøkkel er skjult,

hvor systemfunksjonene omfatter

- en opptaksfunksjon med delfunksjoner for å innhente brukerdata fra en gruppe bestående av lyd-, bilde-, dokument- og posisjonsdata,

- en krypteringsfunksjon med delfunksjoner for å kryptere og dekryptere en brukers brukerdata med brukerens(200) asymmetriske nøkkelpar, og

- en lagringsfunksjon med delfunksjoner for å lagre brukerdata i databasen (121) og mellomlageret (130),

hvorved brukerdata kryptert med brukerens offentlige nøkkel bare kan dekrypteres av en krypteringsfunksjon med lesetilgang til brukerens private nøkkel.

2. System ifølge krav 1, videre omfattende en hashingfunksjon og en hashnøkkel som kombinerer brukerens private og offentlige nøkkel.

3. System ifølge krav 1 eller 2, hvor systemklienten (220) har minst én brukermelding, der hver brukermelding i systemklienten (220) tilsvarer en brukerstatus og en reaksjon i systemserveren (120).

4. System ifølge krav 3, hvor brukermeldingen har en tilsvarende ‘avslutt’-melding som kansellerer den tilsvarende brukerstatusen i systemserveren (120).

5. System ifølge krav 3, hvor brukermeldingen inneholder en tidsperiode.

6. System ifølge et av kravene 3 - 5, hvor brukermeldingen er en ‘forsinket alarm’ med en forsinkelsesperiode, hvor en alarm-reaksjon utføres ved utløpet av forsinkelsesperioden.

7. System ifølge krav 6, videre omfattende en brukermelding ‘endret alarm’ med et nytt tidspunkt for når systemserverens (102) skal utføre ‘forsinket alarm’ reaksjonen slik at ‘forsinket alarm’-reaksjonen fremskyndes eller utsettes.

8. System ifølge et av kravene 3 – 7, hvor brukermeldingen er en opptaks-melding og en opptaksreaksjon omfatter å aktivere opptaksfunksjonen for opptaksutstyr (230-232) nær brukeren (200).

9. System ifølge et av kravene 3 – 8, hvor brukermeldingen er en standby-melding som fører til en forhøyet oppmerksomhet fra systemserveren 120.

10. System ifølge et av de foregående krav, videre omfattende en status for brukerdata som overstyrer en automatisk slettefunksjon for data på disk.

11. System ifølge et av de foregående krav, hvor kansellering av en systemfunksjon krever ekstra autentisering av personen som anmoder om kansellering.

12. System ifølge et av de foregående krav, hvor systemserveren (120) har en funksjon for å sammenholde lokasjonsdata i en forhåndsbestemt sekvens med faktiske posisjonsdata mottatt fra systemklienten (220).

13. System ifølge et av de foregående krav, videre omfattende en systemlogg med tidspunkt for når brukerdata opprettes, leses, endres eller slettes, og en brukerID som identifiserer personen som utførte handlingen.

14. System ifølge et av de foregående krav, videre omfattende en rutine for automatisk sikkerhetskopiering av data i mellomlageret.

15. System ifølge et av de foregående krav, videre omfattende en scenarioliste med meldinger fra en produksjonsversjon av systemet (100) og tider for sending av meldingene, samt et GUI med mulighet for å velge en scenarioliste.