Dansk forsker: Manglende tilfældighed i web-kryptering er 'relativt alvorligt'

To hold forskere har påvist problemer med genereringen af de nøgler, der bruges til kryptering på websteder. Men det kan rettes, påpeger dansk lektor.

Den vigtigste forudsætning for, at såkaldt public key-kryptering er sikkert, er, at det ikke skal være praktisk muligt at gætte den tilhørende private nøgle ud fra den offentlige nøgle.

Men to forskerhold har nu påvist, at det ikke er tilfældet, som beskrevet på Version2 tidligere på ugen.

Læs også: Mystisk fejl i tilfældighedsgenerator gør det muligt at gætte primtal i RSA-algoritmen

De forskerhold har begge fundet identiske offentlige nøgler, skriver de i to i henholdsvis en rapport og [et blogindlæg] https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs).

Da en offentlig nøgle groft sagt genereres ud fra produktet af to store primtal betyder det, at to identiske offentlige nøgler er skabt ud fra de samme to primtal.

Primtallene bruges også til at skabe den private nøgle, og hvis man derfor kan skabe en offentlig nøgle, der er identisk med eksempelvis et betroet websteds offentlige nøgle, så kender man også webstedets hemmelige private nøgle.

Den konkrete sag er ikke noget, der skal tages let på, fortæller en dansk sikkerhedsforsker:

»Jeg vil mene, at det er relativt alvorligt, men det er ikke noget, folk bør bekymre sig om fremover, da størstedelen af problemerne vil blive løst. Men vi bruger alle HTTPS til webtransaktioner, så spørgsmålet er, om en hacker har kendt til problemet og allerede udnyttet det på et websted, der havde en usikker nøgle,« siger lektor Joan Boyar fra Syddansk Universitet, som blandt andet underviser i kryptologi, til Version2.

Svært at implementere ægte tilfældighed

Problemet med de offentlige nøgler skyldes angiveligt den måde, implementeringerne af RSA-krypteringsalgoritmen bruger tilfældighed på, når en ny nøgle skal genereres.

Tilfældighed er en forudsætning for, at det er svært at gætte de store primtal, fordi man på den måde gør det svært at gætte én bestemt primtalsfaktor ud fra et 300 ciffer stort tal.

Imidlertid er det ikke nemt at implementere ægte tilfældighed i software, og det har flere gange ført til sikkerhedshuller i eksempelvis SSL-krypteringen, som bruges på websteder.

»Konklusionen er, endnu en gang, at når et kryptografisk system specificerer, at der skal bruges tilfældighed, så skal man ikke tage for let på det,« siger Joan Boyar til Version2.

Forskerne, som har fundet problemer i mellem 0,2 og 0,4 procent af de offentlige krypteringsnøgler, har i vidt muligt omfang kontaktet dem, der ejer nøglerne for at få løst problemet.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Knud Henrik Strømming

Som jeg forstår problemet, handler det om, at de generatorer af pseudo-tilfældige tal, der er implementeret i diverse nøgle-generatorer, ikke er gode nok. Men hvorfor skal denne generering af tilfældige tal foregå lokalt? Kunne man ikke forestille sig en cloud-baseret service, hvor man anmoder om et tilfældigt tal? Behørigt sikret o.s.v. Så kunne det bagvedliggende system benytte diverse state-of-the-art-systemer, á la systemer baseret på radioaktivt henfald, kosmisk stråling, termisk støj o.l. Det kunne evt. bygges ind i DNS- eller NTP-protokollen, som jo i forvejen er kritiske i forhold til PKI-systemer.

  • 1
  • 0
Johan Brinch

Så kan du ligeså godt sætte en cloud baseret service til at generere nøglerne.

Hvis du kører Linux har du en vanvittig konservativ pseudo random number generator direkte i kernen. Hvis systemet har kørt "længe nok" vil du kunne trække sikre tal ud her. Windows har formentlig en lignende måde at trække uforudsigelige tal på.

  • 0
  • 0
Anonym

Her i tobakstågerne, fik jeg engang et billede af.. Mener at jeg kan huske noget omkring........
Sådan bare et principielt groft et.... Hvor man multiplicerer et par primtal.

Uanset hvad, så vil det være uforsvarligt at benytte kvadratfaktorer.
Altså 13 x 13 eller 17 x 17, osv....

Noget andet er, at hvis man vil være sikker på at bruge en unik sum, så man er nød til at undersøge alle andres sum, for faktorenes orden er ikke ligegyldig.
13 x 17 = 221.
17 x 13 = 221.

I den matrix der dannes af primtal, kan man altså kun anvende under det halve.
Og man er nød til at kende til alle de andres primtal-par, for at være sikker på, at danne en sum der er forskelligt fra alle andres.

Risikoen for at man rammer en del af samme primtal-par som en anden, må altså mindst ligge i, lidt under den halve matrix, delt med antallet af summerne.
( Jo flere certifikater der fremstilles, jo større er risikoen for at ramme en af de andres sum. )

Man kan selvfølgelig bare kigge på den sum der er hos alle de andre, og så dele den med rækken af primtal, og dermed undersøge om man nu også har ramt et primtal-par der ikke bruges.
Det er jo ikke nødvendigt at kigge på både 13 & 17, man skal bare kigge på et af dem. Det første primtal der returnerer et heltal, er en vinder.
Hvilket reducerer besværet i undersøgelsen en smule.

Når man er kommet så langt, at man har fundet 2 unikke primtal, som giver en unik sum, så er man fremme ved noget, som kan have en smule indbygget sikkerhed.
Lige ind til der er en anden, der vil forsøge sig med at vælge et tilfældigt tal-par, så er der igen risiko for, at vedkommende vælger samme tal-par, som en selv.

Helt tilfældigt, kan det nødvendigvis ikke være....
Og der er altid nogen der vinder i Lotto, uanset hvor usandsynligt det er at man vinder.

Jeg skal ikke forsværge, at jeg måske har fået lidt røg i øjet, og vendt regnestokken på hovedet. Så ret mig gerne, hvis jeg er helt galt på den.

  • 0
  • 2
Morten Andersen

@Thomas: Det virker lidt som om du får skrevet/tænkt dig selv op i et hjørne. :P

Du lægger tilsyneladende ud med en præmis om at summen af de to primtal ikke må være ens i.f.t. andres nøgler Hvorfor ikke? Angriberen kender jo ikke summen (hvis han gjorde kunne han umiddelbart løse for primtallene p og q da han i forvejen kender produktet). Og hvorfor skulle man dog undersøge alle andre folk summer? Hele sikkerheden hviler jo på at der er så mange nøgler at vælge imellem og heraf følger også at risikoen for at to brugere vælger samme nøgle er forsvindende. Man har iøvrigt ingen mulighed for at undersøge om andre har samme sum, jf. det med at man ikke kender andres sum. Iøvrigt er det meget usandsynligt at to brugere får samme sum ved en tilfældighed.

Resten af dit indlæg falder vist lidt i kategorien 'Not even wrong' ;)

Måske du skulle starte med at forstå RSA: http://en.wikipedia.org/wiki/RSA

  • 4
  • 0
Anonym

@ Morten

Jeg vil lige prøve med cigaren i den anden mundvig.

Jeg beskriver en sammenhæng i forbindelse med multiplikation af primtal.
Jeg har vist kæmpet lidt med, at holde RSA ude af mit indlæg, men det er ikke lykkedes i forhold til dig.

Jeg vil starte med at henvise til det link du selv sendte link på Wiki.
Under afsnittet; Attacks against plain RSA.
Her skal der ligeledes henvises til et andet link på Wiki:
http://en.wikipedia.org/wiki/Deterministic_algorithm

Jeg prøver at komme ind med et bud på, hvorfor der opstår usikre kombinationer af de multiplicerede primtal.
Det er efter min opfattelse, i det område det er interessant for den manglende tilfældighed.
Der er langt færre muligheder, end det umiddelbart ser ud til, og der bliver lavet mange kombinationer.

Jeg kan også se, at man umiddelbart kan regne sig frem til p & q, når man kender produktet. Det er jo netop hvad jeg beskriver.
Jeg beskriver også at man nødvendigvis kun kan bruge det halve af matrix, ellers vil der kunne opstå 2 ens summer.

Jeg er helt uenig med dig i, at 2 ens summer ud af samme par af primtal, ikke udgør en udfodring for krypteringen, herunder hvor unik en sådan nøgle evt. kan være.

Jeg nævner også, at det er en lineær sammenhæng, hvis man vil beregne et primtal ud fra sum, da man kun har behov for at beregne på det ene primtal.
Det er et stærkt begrænsende, for det område man har behov for at undersøge, hvis man vil finde et par af primtal, ud fra sum.
Det er ikke helt for sjov jeg nævner regnestok.

Jeg vil igen henvise til det link du sendte.
Kigger man under afsnittet; Importance of strong random number generation.
vil man kunne se, at det jeg nævner, når jeg beskriver egenskaberne ved at multiplicerer 2 primtal, til for veksling ligner det der beskrives i afsnittet.

Jeg kommer det pt. ikke nærmere.

Jeg tror ikke på, at der er specielt mange, der med vilje skulle være specielt dårlige til at genererer et tilfældigt primtal. Det ligger et eller andet sted i selve systemet.

Der er andre forhold som medfører svagheder i forhold til kryptering, også i RSA. Det er lidt off topic, men lad mig her nævne et par stykker af dem, jeg anser som mere alvorlige.

a) Det man overhovedet kunne krypterer med en CBM 8296 i 80'erne, har en krypteringsdybde, så man i dag kun kan anse det som klar tekst, med en smule fnidder.
Holdbarheden af krypteret data, er altså forholdsvis lille.
Det har bl.a. betydning for sikkerheden omkring de data, der er gemt og krypteret med gamle systemer, da det er en forholdsvis hurtig udvikling.
Det er kun få år siden, at man diskuterede 32 bit og 128 bit krypteringsdybde og man diskuterer allerede nu, om 1024 bit er sikkert, og anbefaler 2048 bit eller 4096 bit krypteringsnøgler.
Altså er vi rimeligt sikre på, at data de er gemt med f.eks. 128 / 256 bit nøgler, allerede nu forholdsvis lette at kompromitterer.

b) I kryptering, som er afhængig af computerberegning, vil man altid kun kunne redegøre for, at det er en som har tilgang til computeren og nøglen, men man kan ikke redegøre for, hvem det er.
Det giver en falsk tryghed, i en verden hvor keylogger og trojaner, er måden at kompromitterer en kommunikation eller data på.
Specielt for mere eller mindre automatiserede systemer, hvor brugeren ikke selv har indsigt i, eller kan bestemme over nøglen, er det ret alvorligt. "Gamle Fru Olsen" vil simpelthen ikke kunne vide, om hendes nøgle er kompromitteret eller ej.

Med 0,2 % af alle der har et problem, så er der tale om rimeligt mange. Hvis man bare kigger på Danmark, så vil der være tale om 10.000, hvis det overføres til alle Danskere.
Det er lidt alvorligt, for RSA kryptering bliver ellers anset som et fingeraftrykslignende system.

Uden overhovedet at forholde mig til de matematiske sammenhænge, er 0,2 % , i forhold til jura, et alvorligt problem.
Vi må jo håbe, at der ikke er faldet nogen dom på det grundlag.

Jeg syntes jeg har prøvet at tilgå artiklen med en fornuftig indgangsvinkel, ved at komme med et indput omkring nogen sammenhænge i forhold til primtal.

Igen.
Har du et bedre bud på, hvorfor der tilsyneladende opstår samme og / eller svage nøgler ?
Sammenhængene omkring primtal, er jo kun under det halve af opgaven i RSA, der kan sagtens ligge en forklaring et andet sted.

Vi kan jo også bare hakke på hinanden. Og kaste os tilbage i stolen over det. Men hvad laver vi så her på V2.

  • 0
  • 3
Peter Lind Damkjær

Thomas skriver:

Jeg kan også se, at man umiddelbart kan regne sig frem til p & q, når man kender produktet.

Jeg er tilbøjelig til ikke at give Thomas ret, hvis p og q er store. Ellers er det korrekt at RSA er brudt.

Jeg nævner også, at det er en lineær sammenhæng, hvis man vil beregne et primtal ud fra sum, da man kun har behov for at beregne på det ene primtal.

Hvis Thomas med dette mener, at man kan bestemme q, hvis man har fundet p, er det korrekt. Men ligegyldigt for sikkerheden.

Men det synes som om, at Thomas antager, at det er forholdsvist enkelt at lave en liste af primtal i de størrelsesordner som i dag anvendes til RSA eller at risikoen for kollisioner ved valg af primtal er relativt stort (hvis vi antager at primtallene vælges uniformt).

Jeg vil prøve at anskueliggøre, at Thomas' antagelse er forkert:

De primtal der anvendes i dag er i størrelsesorden 1024 bit. Der er 2^1023 tal, som er 1024 bit lange. Ifølge Primtalssætningen er godt og vel en promille af disse primtal. Lad os for nemheds skyld sige 1 / 2^10 (1/1024) af tallene er primtal.

Det giver os et antal af primtal at vælge mellem på ca. 2^1013. Prøv selv at beregne hvor stor en harddisk det kræver at gemme alle disse tal ;-)

Lad os nu antage at der er ca. 2^33 (ca. 8,5 milliarder) mennesker på jorden.

Lad os antage at hvert menneske skal have 2^30 (ca. 1 millard) RSA nøgler. Så skal de bruge 2^31 primtal.

Alt i alt skal vi bruge 2^31 * 2^33 = 2^64 primtal.

2^64 ud af de 2^1013 potentielle primtal er meget, meget lidt (forholdet er 1 / 2^949). Og selv om vi har noget, der hedder fødselsdagsparadokset, er sandsynligheden for kollisioner grænsende til 0.

For at fornemme størrelsesorderne er en dråbe vand i forhold til alt vand på jorden vist nok i omegnen af 1 / 2^80.

Med hensyn til nøglelængder tror jeg at Thomas blander lidt sammen. Det giver kun mening at snakke nøglelængder, når man samtidig siger, hvilken kryptoalgoritme der anvendes. 32, 128 og 256 har aldrig været betragtet som sikkert i forbindelse med RSA, men 128 og 256 anses stadigt for sikkert for en række symmetriske krypteringsalgoritmer.

Baggrunden for de nye resultater er, at visse kryptoprodukter ikke har en god nok metode til at vælge primtal. De vælger så at sige ikke primtallene uniformt. Det kan enten være fordi den benyttede "pseudo random number generator" (PRNG) ikke er god nok eller at den ofte bliver startet med samme tal (seed).

Og løsningen er dermed også relativ enkel: Leverandørerne skal rette PRNG'en eller seede den bedre.

Jeg beklager, at indlægget blev lidt langt.

/Peter

  • 5
  • 0
Erik Jacobsen

For mange år siden mener jeg at jeg hørte om en "smart" måde at lave store primtal på. Det går ikke ud på at finde et tilfældigt 1024-bits tal, og teste om det er et primtal. Enten vil det tage urimeligt lang tid, hvis man vil være sikker, og ellers vil man kun kunne sige, at det med meget stor sandsynlighed er et primtal (hvilket er noget vrøvl, men det svarer vel til at sige, at med meget stor sandsynlighed tager vi ikke fejl, når vi siger at det (nok) er et primtal).

I stedet for starter man med et lille primtal, så laver man en række operationer på det lille primtal, som bl.a. afhænger af tilfældige valg, som laver et større primtal, som altså bevisligt er et primtal. Det gentages til primtallet er stort nok.

Hvis disse valg i hvert trin er noget begrænsede, kan man vel rimelig nemt ramme det samme sidste primtal i nogle få tilfælde af den mange millioner de har testet.

Inden i maven af NemID bliver der vist også genereret primtal på ca. den måde. Kan vi få at vide hvordan de gør? Må vi se kildeteksten?

Måske en dag i fremtiden får vi muligheden for et smart-card eller lignende til NemID, hvor nøglegenerering sker lokalt, så ingen andre kender den resulterende private nøgle. Og det er jo fint nok - men hvad er vores garanti for at der er anvendt "tilstrækkelig tilfældighed" til at finde primtallene? Kildetekst igen?

  • 0
  • 0
Morten Andersen

Erik Jacobsen, jeg kan på trods af en del indsigt i emnet ikke genkende en generering af den type du beskriver -- i hvert fald ikke en der skulle være kryptografisk sikker. Det betyder naturligvis ikke den ikke findes! Men se sidste afsnit i dette indlæg.

I langt de fleste systemer verificerer man kun at primtallet med stor sandsynlighed er et primtal. Men da denne "fejlsandsynlighed" kan gøres vilkårligt lille og præcist kan estimeres spiller det ikke den store rolle. F.eks. kan man acceptere en fejlsandsynlighed på 2^-100. Sandsynligheden for at CPU'en laver en regnefejl under genereringen af primtallene er langt større end for at genereringen fejler pga. denne lille usikker. Begivenheder med en sådan sandsynlighed sker i praksis "aldrig" og alene derfor er det utænkeligt det spiller nogen rolle i de aktulele problemer. Selv hvis det en dag skulle ske at algoritmen tager fejl, så vil det med meget stor sandsynlighed resultere i en RSA nøgle der slet ikke vil fungere (overvejelserne af hvorfor overlades som en opgave til læseren...).

Der findes imidlertid tests der ikke har denne indbyggede usikkerhed.

Et eksempel er AKS-testen som endda kører i polynomiel tid - en stor overraskelse da den blev opdaget i 2002. I praksis er den dog meget langsom.

En mere brugbar algoritme er ECPP som er baseret på elliptiske kurver. Den arbejder ud fra princippet der har en vis lighed med det du beskriver, dog omvendt. Målet er at bevise at et bestemt tal "p" er et primtal. Testen reducerer problemet til at bevise at et (væsentligt) mindre tal "q" er et primtal. q er dog stadigvæk et stort tal, men testen kan også anvendes herpå og problemet reduceres til at vise at et mindre tal "s" er et primtal og så fremdeles indtil man kommer til et tal der trivielt kan vises at være et primtal (f.eks. ved at prøve at dividere med alle primtal under kvadratroden). Algoritmen kører meget langsomgt sammenlignet end de føromtalte probabilistiske men er bestemt praktisk anvendelig. En positiv side-effekt af den er, at den producerer et bevis for at det testede tal er et primtal. Et bevis som en maskine kan verifere gyldigheden af meget hurtigt og med en meget enklere algoritme end den der blev brugt til at skabe beviset. En ulempe ved ECPP er at den er meget "tung" at implementere og involverer en del specialtilfælde, tabeller m.m. Man kan endda risikere at en konkret implementation af algoritmen ikke er i stand til at bevise at alle tal er primtal, hvis den ikke har dækket alle de specialtilfælde der kan opstå undervejs. Det er sikkerhedsmæssigt et problem (i hvert fald teoretisk), da angriberen dermed kan udelukke at disse primtal har været anvendt.

  • 1
  • 0
Anonym

Man kan kigge lidt på hvad man laver i selve systemet.
Man deler først ned i primfaktorer, og deler igen det resultat, ned i andre faktorer.
Det skal jo ende med at nærme sig 1.
Altså 100 %... ½ / ½ = 1..... osv.

Man kan ikke forholde sig til, hvordan man kommer frem til de tilfældige tal der anvendes. Hvordan denne tilfældighedsgenerator er sammensat, kan vi intet vide om. Der kan være et hav af forskellige tilfældighedsgeneratorer, og der er ikke beskrevet noget om, at den ene generator skulle være bedre end den anden.
Vi ved dog, at det i princippet er umuligt at forholde sig tilfældigt til binære tal.
Der er simpelthen 50 % chance for, at der er tale om 0 eller 1, derfor er selve tilfældighedsgeneratoren også kun en kalkulation.
Når man har været alle tilfælde igennem, så kan man jo starte forfra.

Man kan heller ikke forholde sig anderledes til krypteringen, end at det er en kalkulerbar kryptering, der er afhængig af, at det kan "gemmes" i multiplacerbare primtal, som vanskeliggør en kompromittering, da en sådan kompromitterende kalkulation vil tage tid.

Man kan ud fra artiklen, ikke forholde sig til antal af nøgler, for det fremgår ikke. Der må være tale om en jævn spredning over alle nøgler.

Man kan kun forholde sig til de muligheder der er for at opnå unikke tal, ud fra de mulige primtal.

Vi kan kun forholde os til de muligheder vi har, i den størrelse vi kan arbejde med.

Det største heltal jeg kan arbejde med på min 32 bit maskine, uden at benytte mig af flydende notation er 2^32.
Da jeg skal holde mig under kvadratet, fordi jeg skal kunne multiplicerer mit resultat, så er det største heltal 2^16.

Der er 6542 primtal under 2^16.
Det er jo en besnærende nærliggende mulighed, at man ikke rigtigt kan klandre andet for den manglende tilfældighed, end at der simpelthen ikke er flere muligheder.

Den matrix man kan opstille af primtal, har 6542 x 6542 = 42.797.764 muligheder.
Det er det mulige antal af N.
Man KAN ikke have N der er større, hvis man fortsat vil undgå flydende notation, for det kan regnemaskinen ikke håndterer.
I forhold til faktorernes orden, som i dette tilfælde IKKE er underordnet, så kan man kun benytte det halve af mulighederne. 42797764/2 = 21.398.882.
Vi man undgå små tal, f.eks. 3, og fjerner derfor de mindste, f.eks. den nederste 1/4 af muligheder i matrix af primtal, og dermed også de øverste, så reduceres mulighederne tilsvarende. Så bliver der kun omkring 12,5 millioner muligheder tilbage. Osv, osv.
Jeg ved også, at der ikke er tale om de direkte primtal, men der er tale om reduktion på reduktion.

Det er naturligvis et helt andet tal, hvis man benytter sig af henholdsvis 16 bit, eller 64 bit, heltal systemer.
Det giver mulighed for afvigelse, i de mulige resultater, der fremkommer af undersøgelserne.

Vælger man at sige, man vil bruge andre specielt store primtal, i den matrix man opstiller, hvilket ER en mulighed, så reducerer man tilsvarende på det mulige antal primtal i en given talstørrelse, hvilket er en reduktionsfaktor i sig selv.
Man kan udtrykke det som, at man flytter en normalfordelingskurve op i talrækken, men man reducerer tilsvarende de muligheder man kan arbejde med.

Krypteringssystemet ER helt fantastisk, til at krypterer data, i et system hvor der er begrænset krav om levetid for selve krypteringen.
Men det er ikke anvendeligt til at skabe mange unikke og blivende nøgler, jo flere nøgler der skabes, jo tættere kommer man på en gentagelse af en nøglemulighed.

Det er heller ikke anvendeligt, hvis man vil gemme den krypterede data længe.
Vil man gemme data længe, så forsvinder den faktor der gør krypteringen sikker, altså tidsfaktoren.

Det ER jo ikke længe siden, at man arbejdede med 16 bit......

Sikkerheden i et sådant system, er afhængig af tiden. Intet andet.
Kompleksiteten er en konstant, som ikke ændrer sig fordi der er tale om store tal.

Er man 4 der rafler løgn, med hver 4 terninger, så er det mere tilfældigt.

Jeg finder det betryggende, at der stadigvæk er god mulighed for at vinde en øl ;)
Men har det lidt underligt med, at man kalder et sådant system for sikkert, når man VED at det ikke passer.

Det eneste man har stillet op på, er en lappeløsning, hvor man fristforlænger en løsning der ikke hænger sammen.....
Hvorfor gør de det ikke rigtigt, er det fordi de ikke kan ?

Et godt eksempel på en krypteret besked, er Kryptos der står foran CIA:
http://www.nytimes.com/2010/11/21/us/21code.html
Beskeden er let læselig for alle, men fordi ingen ved hvad beskeden siger, eller hvilket kodeord der spørges efter, kan man ikke regne ud hvad der står.

  • 0
  • 3
Morten Andersen

Har du overvejet at en maskine godt kan regne med større tal end 2^32 blot fordi registerstørrelsen er 2^32 ??? På samme måde som at vi kan regne med tal større end 0/1 selvom alt på de laveste niveauer er binært?

Jeg begynder at mistænke du er en 'trold' :-)

  • 2
  • 0
Henrik Kramshøj Blogger

Jeg var også ved at sprutte saftevand over laptoppen, og forresten - hvem bruger en 32-bit maskine idag?

Se eksempelvis http://en.wikipedia.org/wiki/PARI/GP
fundet af min gode kammerat Flemming, vi er ved at arbejde os igennem www.crypto-class.org kurset er gratis, og er igang - så tilmeld jer næste gang det kører hvis I er interesserede i den slags talnørkleri.

  • 0
  • 0
Log ind eller Opret konto for at kommentere