MQV

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 29. april 2016; checks kræver 9 redigeringer .

MQV ( Meneses-Q-Wanstone ) er en godkendelsesprotokol baseret på Diffie-Hellman-algoritmen . MQV giver beskyttelse mod aktive angreb ved at kombinere statiske og midlertidige nøgler. Protokollen kan modificeres til at fungere i en vilkårlig endelig kommutativ gruppe , og især i grupper af elliptiske kurver , hvor er kendt som ECMQV .

MQV blev oprindeligt foreslået af Alfred Menezes , Minghua Q og Scott Vanstone i 1995. Det blev ændret i 1998. Der er en-, to- og trevejsversioner af algoritmen.

MQV er inkluderet i Public Key Cryptosystem Standardization Project - IEEE P1363 .

Patenter for nogle varianter af MQV ejes af Certicom [1] .

MQV har nogle svagheder, som blev rettet af HMQV- algoritmen i 2005 [2] ; se [3] , [4] , [5] .

Både MQV- og HMQV-algoritmer har sårbarheder, der er blevet rettet af FHMQV-protokollen (se [6] )

Beskrivelse

Alice har et statisk nøglepar ( ), hvor hendes offentlige nøgle og hendes private nøgle er. Bob har et statisk nøglepar ( ), hvor hans offentlige nøgle og hans private nøgle. Lad os definere . Lad være et punkt på en elliptisk kurve. Så hvor er rækkefølgen af ​​den anvendte punktgenerator . Der er således første bit af koordinaten for . Derudover indfører vi en cofaktor defineret som , hvor er rækkefølgen af ​​gruppen , og det skal tages i betragtning, at kravet af tekniske årsager skal være opfyldt: [1] .

Trin Operation
en Alice opretter et nøglepar ( ) ved tilfældigt at generere og beregne = , hvor  er et punkt på den elliptiske kurve. Hun sender derefter en midlertidig offentlig nøgle til Bob.
2 Bob opretter et nøglepar ( ) ved tilfældigt at generere og beregne = . Efter parring sender han sin midlertidige offentlige nøgle til Alice.
3 Alice kontrollerer, at den midlertidige offentlige nøgle tilhører gruppen, og at den ikke er et null-element. Derefter beregnes gruppeelementet som , hvor og . Hvis , afviser Alice de data, der er modtaget fra Bob. Ellers accepterer den det beregnede resultat som den delte hemmelighed.
fire Bob kontrollerer, at den midlertidige offentlige nøgle tilhører gruppen, og at den ikke er et null-element. Beregner gruppeelementet som , hvor og . Hvis , afviser Bob data modtaget fra Alice. Ellers accepterer den det beregnede resultat som den delte hemmelighed.

Basisprotokollen er en attraktiv løsning af flere grunde:

  1. Giver implicit nøgleidentifikation og efterfølgende sikkerhed for hver peer.
  2. Den er effektiv ikke kun med hensyn til beregninger, men også med hensyn til gennemløb, da den kun bruger operationer specificeret på marken og et simpelt display. Hver deltagers beregninger (i et groft skøn) består kun af 2,5 multiplikationer - den ene til at generere et midlertidigt nøglepar, den anden til at lave en skalær multiplikation med eller .

Resten af ​​beregningerne er multiplikation med eller . Det er også værd at overveje omkostningerne ved at gange med cofaktoren. Denne kompleksitet (multipliceret med cofaktoren) afhænger dog af gruppens størrelse. For kryptosystemer baseret på elliptiske kurver er denne kompleksitet ubetydelig, da cofaktoren normalt er lille [2] .

Korrekthed

Bobs beregninger :.

Alices beregninger :.

Så tasterne svarer faktisk til [3] -tasten .

Mulige angreb

Den nemmeste mulighed, som en angriber (kryptanalytiker) kan bruge, er at få et certifikat (identifikator), der forbinder hans navn med den offentlige nøgle, som Alice har. Hvis han erstatter Alices identifikator med sin egen identifikator i denne protokol, er der en betydelig chance for, at Bob vil acceptere den givne identifikator uden at lægge mærke til udskiftningen, da han faktisk tror, ​​han taler med Alice. Her er et angreb baseret på kildesubstitution. Dette angreb indikerer behovet for nøgleejerskabskrav: anmoderen skal kende den hemmelige nøgle for at opnå en identifikator, der svarer til den offentlige nøgle. I princippet kunne identitetscentret arrangere en kontrol for duplikerede offentlige nøgler, men dette trin er upraktisk, da det medfører deltagelse af et stort antal identitetscentre. Angriberen skal således anskaffe en identifikator for en ny offentlig nøgle , således at der er et match for den hemmelige nøgle , og sådan at Bob ville beregne den samme delte hemmelighed, når han interagerer med angriberen, som Bob og Alice ville have beregnet, når de interagerer. Den følgende implementering opfylder alle ovenstående mål. Lad os udpege angriberen som Eva [3] .

Trin Operation
en Eve opsnapper Alices midlertidige offentlige nøgle på vej til Bob.
2 Eve vælger et heltal , der hører til mellemrummet og beregner den midlertidige offentlige nøgle som (bemærk, at Eve ikke kender den tilsvarende hemmelige nøgle ). Hvis , Eve gentager dette trin med et andet heltal .
3 Eva beregner det statiske par som ,

.

fire Eve modtager en identifikator for sin statiske offentlige nøgle . Således kender hun den tilsvarende hemmelige nøgle . Derfor opfylder det kravene til nøgleejerskab.
5 Eve indleder protokollen med Bob ved at sende hendes midlertidige offentlige nøgle .
6 Eve modtager Bobs midlertidige offentlige nøgle og giver den til Alice.

Som et resultat af dette angreb vil Alice tjekke Bobs ID og beregne den delte hemmelighed , mens Bob vil modtage og verificere Evas ID og beregne den delte hemmelighed , som , hvor defineret tidligere og .

Bobs nøgle vil være den samme, som den ville være, hvis Bob interagerede med Alice.

.

Eve skal have en identifikator for sin statiske offentlige nøgle på det tidspunkt, hvor Alice starter protokollen. Alice kan således bemærke en forsinkelse mellem det tidspunkt, hvor hendes midlertidige offentlige nøgle sendes, og det tidspunkt, hvor hun modtager Bobs ID.

Angreb modforanstaltninger

Først og fremmest er det første trin at inkludere en operation i protokollen, der vil blive reserveret til at kontrollere eksistensen af ​​nøglen. Dette tip gælder for alle godkendelsesprotokoller. For at bestå Bobs verifikation skal Eve bestå en ekstra kontrol. En anden modforanstaltning, der kan indføres i protokollen, er, at parterne udveksler envejs-hash af deres midlertidige offentlige nøgler, før de udveksler de midlertidige nøgler. Udvekslingsmekanismen i dette tilfælde er virkelig vigtig. Hver part skal være sikker på, at det andet medlem rent faktisk har modtaget "pakken", før de sender ham en midlertidig offentlig nøgle. Bekræftelse af dette faktum kan opnås ved den passende sekvens. For eksempel sender Alice sin bekræftelse, Bob modtager den og sender sin bekræftelse. Alice modtager Bobs bekræftelse og sender hendes nøgle. Da Bob modtager Alices nøgle, sender han sin egen nøgle. Uden en sådan sekvens, for eksempel, hvis Bob og Alice begge sender på samme tid, vil denne protokol være sårbar over for nogle typer angreb [4] .

Lad os tage et kig på andre modforanstaltninger.

  1. Forsinkelsesdetektor er et alternativ, der ikke bruger kryptografi. Implementering af den såkaldte delay checker. Siden (Bob eller Alice) vil afslutte protokollen, hvis responstiden på den anden side overstiger den tilladte værdi angivet i protokolimplementeringen. Når Eve anmoder om en identifikator, kan dette trin kræve yderligere tid (der er dog måder at omgå denne kompleksitet). Desuden vil den ekstra tid være sammenlignelig med tiden for andre operationer involveret i protokollen. Denne modforanstaltning hjælper dog ikke i tilfælde af et flertrinsangreb.
  2. "Record Identifier". Modtageren kan anmode om bevis for identifikatorens alder. Et nyligt erhvervet ID kan tages som bevis på et angreb. Derefter lukkes kommunikationskanalen med angriberen.
  3. Identifikation af deltagere gennem beskeder. Hoveddesignprincippet for protokoller er, at meddelelser skal indeholde nok information til at undgå fejlfortolkning. Følgelig skal meddelelser, der er beskyttet med en fælles hemmelighed, identificere de deltagere, der er involveret i transmissionen. En sådan identifikation ville forhindre muligheden for fejlfortolkning.

Alle ovenstående forbedringer introducerer minimale ændringer af protokolstrukturen. Det er værd at bemærke, at der ikke er noget formelt bevis for den fuldstændige sikkerhed af protokollen, som er ændret ved hjælp af ovenstående anbefalinger.

Se også

Noter

  1. Kaliski, 2001 , s. 277.
  2. Kaliski, 2001 , s. 278.
  3. 1 2 Kaliski, 2001 , s. 280.
  4. Kaliski, 2001 , s. 281.

Litteratur

Links