OCRA

OCRA ( OATH Challenge-Response Algorithm , RFC 6287. ) er en algoritme , der kombinerer mulighederne for klientgodkendelse , gensidig godkendelse og transaktionssignering ved hjælp af engangsadgangskoder . Det er en modifikation af HOTP- algoritmen . Den største forskel mellem OCRA og HOTP er, at den bruger en tilfældig værdi modtaget fra serveren som input, og ikke en hændelsestæller.

Historie

OATH -samarbejdet har siden 2004 udviklet engangsadgangskodebaserede autentificeringsalgoritmer . På grund af den hurtige udvikling af mobilindustrien var disse algoritmer meget populære. I slutningen af ​​2005 udkom HOTP. HOTP-algoritmen bruger en tidsuafhængig tæller til at generere engangsadgangskoder. Dette undgår desynkronisering, når der er lang afstand mellem klienten og serveren. [1] [2]

OATH introducerede TOTP- algoritmen i 2008, som er en modifikation af HOTP. [3] TOTP til autentificering genererer en adgangskode baseret på tid, i modsætning til HOTP, hvor adgangskoden blev genereret baseret på en tæller. Denne adgangskode er kun gyldig i et vist tidsrum. På grund af dette er problemet med desynkronisering af noder placeret langt fra hinanden delvist løst, mens der ikke er noget tab af kommunikation på grund af utilsigtet eller bevidst nulstilling af tællere. [fire]

I efteråret 2010 modificerede OATH TOTP ved at introducere OCRA-algoritmen. Dens største fordel er, at det er muligt for serveren at autentificere. Algoritmen er også i stand til at skabe en elektronisk digital signatur , og serveren kan også autentificeres. [en]

Generel ordning

Anvendte betegnelser: [5]

Typiske driftsformer

Envejsgodkendelse

I denne tilstand skal serveren sende en tilfældig anmodning til klienten, som igen skal give et gyldigt svar for at blive autentificeret. Begge parter skal på forhånd være enige om den hemmelige nøgle K. [4] [5]

I dette tilfælde skal følgende parametre bruges: [5]

Handlingsalgoritme: [5]

  1. Serveren sender en Q-anmodning til klienten.
  2. Klienten danner R = OCRA(K, {[C] | Q | [P | S | T]}) og sender svaret R til serveren.
  3. Serveren tjekker svaret R. Hvis svaret er korrekt, sender den OK til klienten, ellers sender den NOK.

Gensidig godkendelse

I denne tilstand godkender klienten og serveren hinanden. Klienten sender en tilfældig anmodning til serveren, som genererer et svar og sender det til klienten sammen med sin anmodning. Klienten tjekker først serverens svar for at sikre, at det er korrekt. Derefter danner klienten sit svar og sender det til serveren. Serveren tjekker klientens svar og afslutter derved den gensidige autentificeringsproces. Begge parter skal på forhånd være enige om den hemmelige nøgle K. [4] [5]

Serverparametre for svar: [5]

Klientmuligheder for svar: [5]

Handlingsalgoritme: [5]

  1. Klienten sender en QC-anmodning til serveren.
  2. Serveren genererer RS ​​= OCRA(K, [C] | QC | QS | [S | T]). Sender RS ​​og dens QS-anmodning til klienten.
  3. Klienten tjekker serverens svar og beregner sit eget svar RC = OCRA(K, [C] | QS | QC | [P | S | T]). Sender til RC-serveren.
  4. Serveren kontrollerer klientens svar, og hvis det lykkes, sender den en godkendelsesbekræftelse.

Simpel signatur

Serveren skal sende en vis værdi til klienten til signatur. Denne værdi kan for eksempel være den information, der skal signeres, eller en hash-funktion fra denne information. Begge parter skal på forhånd være enige om den hemmelige nøgle K. [5]

Følgende parametre bruges: [5]

Handlingsalgoritme: [5]

  1. Serveren sender en signaturanmodning Q til klienten.
  2. Klienten genererer SIGN = OCRA(K, [C] | QS | [P | T]) og sender et SIGN-svar til serveren.
  3. Serveren kontrollerer svaret R. Hvis svaret er korrekt, sender det et OK til klienten.

Servergodkendelsessignatur

I dette tilfælde kontrollerer klienten først serverens ægthed, og først derefter beregner og sender den elektroniske signatur. Klienten sender først en tilfældig værdi som en anmodning til serveren, hvorefter serveren sender klienten sit svar på sin anmodning og information til signering. Begge parter skal på forhånd være enige om den hemmelige nøgle K. [5]

Serverparametre for svar: [5]

Klientmuligheder for svar: [5]

Handlingsalgoritme: [5]

  1. Klienten sender en QC-anmodning til serveren.
  2. Serveren genererer RS ​​= OCRA(K, [C] | QC | QS | [T]). Sender RS ​​og dens QS-anmodning til klienten til underskrift.
  3. Klienten tjekker serverens svar og beregner sit eget svar SIGN = OCRA(K, [C] | QS | QC | [P | T]). Sender et SIGN til serveren.
  4. Serveren kontrollerer klientens svar og sender, hvis det lykkes, en OK-godkendelsesbekræftelse.

Implementeringskrav

Algoritmens pålidelighed

Godkendelsessystemer baseret på engangsadgangskoder er ret pålidelige. Samtidig har OCRA en række fordele i forhold til sine forgængere, TOTP- og HOTP-algoritmerne. [fire]

En af de seriøse angrebsmetoder er spoofing af godkendelsesserveren, som kan være effektiv ved angreb på TOTP og HOTP. I dette tilfælde modtager angriberen data fra brugeren og kan bruge dem til at kommunikere med serveren. Men i tilfældet med OCRA-algoritmen, som fungerer efter "request-response" metoden, skal angriberen fungere som mellemled mellem brugeren og serveren. En angriber skal også erstatte klientadressen for at modtage data fra serveren og bruge den til at kommunikere med klienten. [fire]

OCRA-algoritmen kan også implementeres til at være modstandsdygtig over for angrebet baseret på timeren eller tæller-desynkroniseringen, som HOTP og TOTP er underlagt, da disse parametre kan kombineres i OCRA. Når en tæller introduceres, vil afsendelse af en gentagen besked fra en angriber ved hjælp af Man-in-the-middle-metoden mislykkes , da tælleren på serversiden (eller klienten, afhængigt af hvem angriberen forsøger at efterligne) vil ændre sig og meddelelsen vil blive kontrolleret allerede ikke den værdi, som den blev oprettet med. Det er også muligt at ændre den tid, hvori adgangskoden er gyldig, afhængigt af afstanden mellem klienten og serveren, for at undgå desynkronisering. [fire]

Sammenligning med jævnaldrende

De vigtigste konkurrenter til OCRA blandt de algoritmer, der arbejder med "request-response" metoden, er SCRAM og CHAP . I forhold til dem har OCRA både fordele og ulemper. Alle tre algoritmer understøtter gensidig godkendelse, men CHAP blev oprindeligt ikke designet til at være en vigtig del af algoritmen. Også i CHAP udføres hver dataoverførsel som en pakke, der angiver formålet med denne pakke, dens længde osv. Dette øger mængden af ​​overførte data og kan forringe algoritmen på en langsom forbindelse. Men denne form for beskeder giver dig mulighed for at udføre nogle yderligere operationer, for eksempel at ændre det hemmelige ord, der er gemt af både serveren og klienten. OCRA har ikke denne funktion; Algoritmen understøtter ikke muligheden for at ændre hemmeligheden. I SCRAM har serveren og klienten nøglearrays beskyttet af et salt . Dette giver dig mulighed for at ændre nøglen med hver ny godkendelsessession. SCRAM har også evnen til at opdage et angreb ved hjælp af "mand i midten"-metoden. Ved vellykket detektering af et sådant angreb stoppes kommunikationen mellem klienten og serveren. OCRA og SCRAM bruger, i modsætning til CHAP, en tilfældig værdi modtaget fra serveren som et argument for kryptofunktionen. OCRA har mulighed for at oprette en elektronisk signatur, mens SCRAM bruger en signatur til at godkende. Serveren (klienten) sender parametrene for kryptofunktionen og chifferteksten til klienten (serveren). Derefter dekrypterer klienten (serveren) teksten, signerer den og sender den til serveren (klienten). Når signaturen er autentificeret, anses godkendelsen for at være bestået. OCRA har, i modsætning til sine konkurrenter, evnen til at bruge tællere og timere som yderligere beskyttelse mod hacking. [6] [7]

Noter

  1. ↑ 12 Nathan Willis, 2010 .
  2. ↑ HOTP-baseret brugergodkendelsesskema i hjemmenetværk, 2009 .
  3. ↑ OATH indsender TOTP: Time-Based One Time Password Specification til IETF .
  4. ↑ 1 2 3 4 5 6 Konceptet med engangskodeord i opbygningen af ​​et autentificeringssystem, 2006-07, 2006-08 .
  5. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 RFC 6287, 2011 .
  6. ↑ RFC 5802, 2010 .
  7. ↑ RFC 1994, 1996 .

Kilder