Micro-sd-kaart voorkomt afluisteren mobiele telefoon

Een nieuwe micro-sd-kaart kan volgens de Duitse fabrikant een mobiele-telefoongebruiker behoeden voor het afluisteren van die telefoon. De sd-kaart heeft een 'cryptocontroller' aan boord, die gesprekken van versleuteling voorziet.

De versleuteling werkt met keys die tot 521 karakters lang zijn, waardoor de gebruiker moeilijk afgeluisterd kan worden, meldt Symbian-Freak. De micro-sd-kaart kan ook gewoon voor opslag worden gebruikt en kan in telefoons worden gebruikt. Veruit de meeste moderne telefoons hebben een micro-sd-slot aan boord, ook goedkopere modellen.

De encryptie die wordt gebruikt is gebaseerd op 'elliptic curve' cryptografie. De versleuteling heeft maximaal 521 karakters en zou even veilig zijn als rsa-encryptie met 15.360 karakters. De beveiliging is volgens de fabrikanten de meest geavanceerde op de markt van micro-sd-kaarten.

Fabrikanten Giesecke&Devrient en Phison Electronics, die geheugenproducten maken als joint-venture, zullen de kaart introduceren tijdens de beurs Cartes&Idenitification, die volgende week in Parijs wordt gehouden. Vermoedelijk worden dan ook details bekend over hoe de kaart precies werkt en of het bijvoorbeeld nodig is dat beide gesprekspartners tijdens een telefoongesprek de kaart nodig hebben.

De kaart heeft een opslagcapaciteit van 2GB en werkt op Symbian, Windows Mobile, BlackBerry, Android en op Linux gebaseerde besturingssystemen. Het is onduidelijk hoeveel het kaartje zal kosten.

Reacties (78)

[Kaw]

De versleuteling heeft maximaal 521 karakters en zou even veilig zijn als rsa-encryptie met 15.360 karakters.

Cryptokundig is dit een loze uitspraak. Je beveiliging is zo sterk als de zwakste schakel. Je kunt wel met een sleutel van 521 karakters (512 lijkt me logischer?) een rsa-sleutel maken met 15.360 karakters, maar wat scheelt het? Daarnaast is de sleutelgrootte vaak niet van doorslaggevende aard. Vaak wordt de sleutel weer door een hashalgorithme gehaald die daadwerkelijk voor het encrytie-algoritme gebruikt wordt. Voor het verhaal is het dus nuttiger om te weten wat nu precies het algoritme is. Als dat RSA is, dan is de beveiliging niet spectaculair, maar wel afdoende.

Edit: Moet beter lezen... Het gebruikte algoritme wordt gewoon genoemd. Toch blijft het verhaal over die sleutel in takt.

[Reactie gewijzigd door Kaw op 22 juli 2024 18:41]

[GemengdeDrop]

Toch blijft het verhaal over die sleutel in takt.

Niet echt hoor. De sleutellengte wordt genoemd met betrekken tot het algoritme dat voor de uitwisseling van sleutels zorgt. Elliptic curve werkt anders als RSA, daarom kan een andere sleutellengte verantwoord zijn.

Het gaat om het probleem hoe je over een onveilige verbinding tussen twee partijen een gezamenlijke sleutel kan afspreken zonder dat een afluisteraar achter die sleutel kan komen. De veiligheid van de daarvoor gebruikte algoritmes hangt dan samen met de moeilijkheid van het wiskundige probleem dat daar achter zit. Twee verschillende algos kunnen dus totaal verschillende sleutellengtes hebben die als 'veilig' beschouwd kunnen worden.

Het resultaat van de uitwisseling kan dan inderdaad gehashed worden om een sleutel te bekomen voor een symmetrische cypher. In de praktijk moet dus het aantal bits dat geleverd word door de uitwisseling hoger zijn als het aantal bits dat je gebruikt voor de symmetrische cypher.
Voor het symmetrische AES bijvoorbeeld wordt in het algemeen 256 bits als perfect veilig beschouwd. Indien de gekozen symmetrische sleutel 256 pure random bits heeft dan is er geen veiligheids probleem met betrekking tot het symmetrische deel van de versleuteling. De tradeoff moet dus zodanig zijn dat de moeilijkheid om de sleuteluitwisseling te kraken even hoog of hoger is als de moeilijkheid om de symmetrische sleutel te kraken. Op die manier garandeer je dat voor elke stap in het key-agreement proces de betreffende stap geen beperking betekend voor de veiligheid van de volgende stap.

In de praktijk is uitwisseling van sleutels over een onveilig kanaal een moeilijk proces. Daarom heb je in verhouding erg veel bits nodig. Je zou het een beetje kunnen zien als dat een groot gedeelte van die bits niet helemaal 'random' zijn voor de afluisteraar. Uit het grote aantal bits van de asymmetrische crypto moet dus voldoende random bits voor je symmetrische cyper te destilleren zijn. Als dat niet zo is dan doe je het voordeel van de gekozen sleutel lengte van je symmetrische cyper teniet. Je wilt uiteindelijk dat het sleuteluitwisselingsproces even moeilijk of moeilijker is te kraken dan het symmetrische algo.

Kennelijk levert eliptic curve crypto bij 521 bits even veel onvoorspelbare bits op als RSA bij 15360. Die aantallen zijn niet echt in beton gegoten. Met onvoorspelbaar wordt dan bedoeld: hoeveel van die bits moet je in de praktijk gaan bruteforcen.

De zwakste schakel wordt dus weldegelijk bepaald door het aantal bits, maar de dezelfde mate van zwakheid heeft voor elke stap in de chain een andere aantal bits nodig.
Overigens, het precieze aantal bits boeit niet, of het er nu 512 of 521 zijn, zolang je hash algo niet makkelijker te bruteforcen is als de rest van de algos en zolang het geen andere zwakheden kent en zolang als er in die 521 bits maar genoeg random informatie zit voor je symmetrische sleutel dan kan je altijd een manier vinden om de juiste sleutelengte te bekomen. Desnoods pad je die 521 bits eerst met een pseudorandom salt (die helemaal niet geheim hoeft te zijn) naar 1024 bits en vervolgens xor je de eerste helft van dat aantal bits met de tweede helft om op 512 bits uit te komen. Als je hash algo echt goed is kan dit zonder problemen voor de veiligheid.

[ATS]

Het punt wat het artikel denk ik wil maken, is dat sleutellengtes weinig zeggen als je niet weet voor welk algoritme de sleutel bedoeld is. Kennelijk is de sterkte bij een eliptic curve encryptie met een 521 "karakter" lange sleutel (vreemd, meestal gebruik je bits om de sleutellengte aan te geven) even sterk als een RSA algoritme met een 15.360 karakters lange key.

[Manu_]

Volgens mij begrijp je niet helemaal wat er bedoeld wordt. Er wordt gezegd dat 521 bits ECC even veilig is als 15360 bits RSA. Dit komt doordat RSA op priemfactorisatie gebaseerd is, en ECC het op discrete log probleem. Het discrete log probleem is dus moeilijker op te lossen.

Verder is het echt een 521 bits key, zie bijvoorbeeld hier.

[Reactie gewijzigd door Manu_ op 22 juli 2024 18:41]

[Pietjebelll]

Kan iemand mij vertellen wat de link is tussen het opslaggeheugen en de controller die het netwerkverkeer regelt?

[Adion]

Ik vermoed dat er enerzijds op het opslaggeheugen van het kaartje software staat voor je toestel die ervoor zorgt dat het gesprek geencrypteerd word en weer gedrycpteerd bij de ontvanger.
Anderzijds zal het kaartje blijkbaar de hardware bezitten om deze encryptie hardware-matig uit te voeren.
Dit zou aangestuurd kunnen worden door naar een bepaald bestand of bepaalde locatie op het kaartje te lezen of te schrijven, waarna de controller in het kaartje de data doorstuurt naar de encryptie-hardware ipv naar het flash-geheugen.

[The-Source]

Geen link denk ik zelf. Zoals ik het vermoed gebruikt dit kaart de SDIO standaard welke vroeger heel soms voor wifi kaartjes werden gebruikt. Maar ik weet niet of dat met de verkleining van slots nog steeds mogelijk is.

[DrClaw]

SD is inderdaad alleen maar een geheugenkaartje, maar er bestaat ook zoiets als SDIO, secure digital IO dus.

via dezelfde aansluiting als SD kun je dan cameraatjes, wifi modules en dergelijke aansluiten. Maar dan moet je telefoon dus wel SDIO ondersteunen.

http://en.wikipedia.org/w...l_Input_Output_.28SDIO.29

[Roland684]

SD staat voor Secure Digital, dus een SD-kaartje moet iets van encrypto-engine bevatten, al wordt deze funtion in de praktijk zelden gebruikt.
En nu heeft eenbedrijf het dus mogelijk gemaakt om de crypto-engine ook los te gebruiken, niet alleen voor het en-/decrypten van zijn eigen geheugen.

[Glaanie]

Uhm, hoe werkt het kaartje dan? Hoe worden de gesprekken doorgesluist door dit kaartje? En dan nog, heeft de ontvanger ook ditzelfde kaartje met de juiste key nodig? Zoveel vragen

[Dancing_Animal]

Je belt elkaar eerst onveilig op, spreekt over die onveilige lijn een key af en belt elkaar daarna weer terug [/lollig]
Vroeg het me ook al af, volgens mij kan dit bijna niet werken met toestellen die er niet op voorbereid zijn. Soort sd crypt ready ofzo.

[IStealYourGun]

Een mogelijke workaround zou zijn dat je voor elk nummer een specifieke key hebt die op voorhand op beide kaarten bekend zijn. Als ik me niet vergis deden de (Soviet) Russen dat zo. Hun spionnen kregen een boekje met sleutels mee en elk bericht kon gedecodeerd worden met een sleutel. Kwam er een bericht niet aan of viel het in handen van de vijand (USA), dan was het niet meer synchroon en waardeloos.

Edit: niet geheel correct, maar het lijkt er wel een beetje op One-Time Pad

[Reactie gewijzigd door IStealYourGun op 22 juli 2024 18:41]

[jvroosmalen]

Het uitwisselen van een key is alleen nodig bij symmetrische encryptie. Als ik mijn college Cryptologie goed herinner was elliptic-curve encryptie een vorm van public-key encryptie. Dat wil zeggen dat het analoog aan RSA, niet nodig is een geheime sleutel af te spreken.
Las jij op internet bij een webwinkel veilig iets wil kopen hoef je ze ook niet te bellen om een sleutel af te spreken, toch is het veilig.

Een ander alternatief is om bijvoorbeeld Diffie-Hellmann key-exchange toe te passen. Hiermee kun je over een onveilig kanaal toch een geheime sleutel afspreken. Waar je dan wel voor moet uitkijken is een man-in-the-middle attack waar iemand zich er tussen zet en een veilig kanaal met zowel A als B afspreekt en dan het hele gesprek steeds ontsleuteld, beluisterd en dan versleutelt weer doorstuurt.

Als je en veilige communicatie wilt, en zeker wilt zijn met wie je praat ontkom je er niet aan om sleutels/certificaten van te voren te delen. Of via een vertrouwde derde persoon uit te wisselen.

[IStealYourGun]

Je hebt duidelijk meer kennis, dan mij over het onderwerp en zou je hiervoor gerust een +2'tje willen geven.

Maar op het einde zeg je wel meteen het probleem bij dit soort afluister technieken. Dit kan volgens mij enkel en alleen door een man-in-the-middle-attack. Wanneer het aankomt op internet bestaan er tegenwoordig al (commerciële) producten die daar heel ver in gaan. Op mijn vorig werk hadden we zo een proxy server staan waarmee, mits een kleine aanpassing, transparanten man-in-the-middle-attack's konden uitvoeren waarmee ook ssl verkeer mooi werd onderschept en in plain-text werd opgevangen.

Volgens mij is enkel quantum encryptie op dit moment een van de enige waarbij een man-in-the-middle-attack zo goed als onmogelijk is, maar dat beperkt zich echter tot fiber netwerken.

[thegve]

SSL werkt met vooraf geinstalleerde certificaten (sort-off). In het certificaat van de partij waarvan jij de website bezoekt (via SSL) zit een naam opgeslagen. Deze naam is hier in gezet (versleuteld), door een vertrouwde derde ( Een Certificate Authority ; CA ). Als je dit zou proxy'en, zou ofwel de naam niet meer overeenkomen (als je het met een ander certificaat ondertekend), ofwel hij is niet meer ondertekenend door de CA.
Zelf opnieuw versleutelen mbv de originele sleutel kan niet.
Vooraf zitten in je browser dus de sleutels van een aantal CA's opgeslagen, als de verbinding is versleutel met een sleutel die daar niet (direct of indirect) vandaan komt, begint je browser te piepen.

[Reactie gewijzigd door thegve op 22 juli 2024 18:41]

[IStealYourGun]

Mooie uitleg, maar google eens naar Bluecoat en je zal verschillende verwijzingen vinden naar hun proxy systemen waarmee het perfect mogelijk is https verkeer transparant te decrypteren zonder dat de je als eindgebruiker dit door kan hebben.

[arjankoole]

De russen hanteerden een iets andere methode (die je al uitlegd), maar dat is nog altijd een one-time pad. De russen waren er dol op. (en terecht).

Als ik me niet vergis zijn de Amerikanen later weer one-time pads gaan toepassen, maar ditmaal via computer systemen. Dat maakte het veel gebruikersvriendelijker en minder foutgevoelig dan het handmatige werk.

[SavageX]

Het zijn natuurlijk mooie ontwikkelingen, maar ook best tegenstrijdig, helemaal met alle ellende die aan de gang is hedendaags.

Of zal er een "backdoor" in zitten voor veiligheidsdiensten.

[Reactie gewijzigd door SavageX op 22 juli 2024 18:41]

[i-chat]

ik hoop het niet, want backdoors maken het hacken zoveel eenvoudiger, en dan heb je uiteindelijk dus alsnog NIETS aan je veilige telefoon. lijkt me prettig als je 'bedrijfs gevoelige info 'verliest' omdat bedrijf x jouw moedwillig een lek product heeft verkocht

[PBX_g33k]

Als ze het product in Amerika op de markt willen brengen, zijn ze verplicht een backdoor in te bouwen en de master-key(s) aan de overheid te geven.

Ik had via-via een wetsartikel gevonden over het onderwerp. Zal het hier plaatsen zodra ik het weer heb gevonden.

[daan!]

Begrijp ik het goed dat beide bellers een dergelijk kaartje nodig hebben voor versleuteling?

[Nokian95dude]

Lijkt me dat als 1 van beide het kaartje heeft het al effect heeft namelijk dat de mob met t kaartje niet afgeluisterd kan worden en de ander zonder wel... Dus heet wel deggelijk effect.

[wizzkizz]

Lijkt mij niet, want hoe moet de ontvanger het versleutelde gesprek dan ontsleutelen? Dat kan niet, anders zouden meeluisteraars dit ook kunnen. Ergo, beide telefoons moeten deze versleuteling ondersteunen, waardoor dit niet geschikt is om "normaal" beveiligd te bellen.

[IStealYourGun]

Als je het aan de logische kant bekijkt zal je beiden wel eentje nodig hebben.
Als GSM A beveiligd is en GSM B niet dan luister je gewoon GSM B af.

En dat is volgens mij zijn grootste zwakte. Voor hoog geplaatste personen of speciale politie eenheden lijkt dit nog handig, op voorwaarde dat beide bellers zo een kaartje hebben. En natuurlijk heeft dit ook weinig nut in een overvolle trein (naar Leuven bijvoorbeeld) waar iedereen kan meeluisteren.

Voor de gemiddelde consument heeft het volgens mij weinig nut. Als er iemand echt zo geboeid is om te weten wat ik s'avonds ga eten, dan mogen ze mij afluisteren, maar het is een stuk makkelijker om het mij gewoon te vragen.

[Reactie gewijzigd door IStealYourGun op 22 juli 2024 18:41]

[Jut]

Maar, als je alleen het nummer van crimineel A hebt, weet je dan wel welk nummer hij belt of wordt dat ook versleuteld.

[TheekAzzaBreek]

Het gebelde nummer kan niet versleuteld worden, anders weet de centrale niet welke verbinding gemaakt moet worden.

[Verwijderd]

Maar de afzender kan wel versleuteld worden. Zeker als er gebeld wordt via het UDP protocol of een vergelijkbaar umts protocol o.i.d. .

Vervolgens kunnen er vergelijkbare dummy pakketjes naar bijvoorbeeld 100 dummy ontvangers verstuurd worden. Je zou dan 100 IP nummers na moeten trekken omdat je niet weet wie de 'echte' ontvanger is. Dat kost in ieder geval tijd ( = geld ).

Een andere veel gebruikte manier om allerlei "traffic analysis" methoden te ontwijken is het gebruik van (goedkope) wegwerpmobieltjes, waarbij ook de simkaart met het toestel weggeworpen wordt om de week of zo.

Veel encryptie en wachtwoord beveiliging hebben echter als zwakte dat het doelwit ook op vele eenvoudigere manier kan afgeluisterd en afgekeken kan worden. De auto en verblijfplaats lenen zich gemakkelijk voor het afluisteren van alle gesprekken (ook niet telefonisch) en het meekijken op het beeldscherm en toetsenbord. Er is mij geen encryptie bekend die het meekijken op het beeldscherm via een camera kan voorkomen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:41]

[bbob]

Weet je wat je je beter kan afvragen over deze aanbieder toch geen backdoor heeft voor veiligheidsdiensten.

Cryptophone is een voorbeeld van software waarvan je de broncode kan bekijken op backdoors en dus kan zien of die er zijn. Dit soort kaarten geeft toch een schijnveiligheid aangezien ze closed source is en je dus nooit kan weten of er een backdoor in zit.

[Verwijderd]

Je noemt hier een sterk punt.

Opensource wil echter nog niet altijd zeggen dat er geen backdoors in zitten.
Het is geen garantie.

Vooral met ingewikkelde software kan het soms moeilijk zijn om vast te stellen of het algoritme een ( al dan niet met opzet ingebrachte ) zwakke schakel heeft. Soms moet er misschien zelfs een team wiskundigen aan te pas komen.

Verder moet je na de code helemaal te hebben gecontroleerd (flinke klus) zelf het programma compileren uit de broncode, want een hash is geen garantie dat er geen backdoor in de binary executable zit. En de compiler die je gebruikt moet natuurlijk ook op backdoors gecontroleerd worden

Maar een onwaarschijnlijke zwakheid is natuurlijk bij uitstek de beste plaats om een exploit aan te brengen omdat hij niet zo snel ondekt wordt.

Maar als je echt zekerheid wilt maak je een simpel java-XOR programmaatje en zet je op het geheugenkaartje een one-time pad sleutel. Met 2gb kun je heel wat smsjes versleutelen. Goed geimplementeerde one-time pad versleuteling is de sterkste vorm van encryptie en is relatief makkelijk te begrijpen en programmeren in een paar regels.

Encryptie kan echter ook reden zijn voor achterdocht. Daarom kun je ook ogenschijnlijk 'onschuldige' sms-jes gebruiken die iets anders betekenen.

Of begin je eigen nummerstation http://nl.wikipedia.org/wiki/Nummerstation

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:41]

[DaDolce]

Logisch bekeken heb je dus 2 van zulke soort kaartjes nodig...Maar als je toch wilt afluisteren kun je dan niet nog zo'n kaartje halen? Als de ontvanger het kan decrypten, dan kun je als afluisteraar met zo'n kaartje hetzelfde doen lijkt me...Of mis ik iets belangerijks?

[robvanwijk]

Of mis ik iets belangerijks?

De versleuteling werkt met keys

[i-chat]

pub/priv key onderhandelingen tussen de gsm voor het gesprek kan beginnen...
je hebt dus waarsch gewoon 2 van deze kaartjes nodig, en elkaars key

[AugmentoR]

Die sms je dan toch even onversleuteld door

[Glashelder]

Public key kan je gerust onversleuteld doorsturen

[flamingworm]

idd, de ontvanger kiest 2 (enorm grote) priemgetallen en vermenigvuldigd die, vervolgs wordt het product onversleuteld doorgestuurd en encrypeerd de verzender zijn bericht hiermee. Als het bericht verzonden is kan de ontvanger met behulp van zijn gekozen priemgetallen het bericht weer decrypten. Een product van 2 enorm grote priemgetallen is natuurlijk een gigagetal en het kan jaren computerwerk kosten om dit getal in priemgetallen te ontbinden.

[robvanwijk]

idd, de ontvanger kiest 2 (enorm grote) priemgetallen [etc. etc.]

Dat is RSA. Hier wordt een andere methode gebruikt:

De encryptie die wordt gebruikt is gebaseerd op 'elliptic curve' cryptografie.

quote: http://en.wikipedia.org/wiki/Elliptical_curve_cryptography

Early public-key systems, such as the RSA algorithm, are secure assuming that it is difficult to factor a large integer composed of two or more large prime factors. For elliptic-curve-based protocols, it is assumed that finding the discrete logarithm of a random elliptic curve element with respect to a publicly-known base point is infeasible.

[alaintje]

Zijn we daar ook van af.

ontopic: hoe werkt dat dan in godsnaam? de CPU van de smartphone moet dan toch weer alles in en uitpakken ?
Dit kan nooits verantwoord voor de accu zijn

[i-chat]

daar kun je ook gewoon een co-prosessor voor inzetten. net zoals dat met een 'gpu' werkt of met een hardware-modem

[alaintje]

En dan kost dat toch weer stroom en ruimte.
Dit gebruiken ze maar voor die 1 % zakelijke klanten die zo bang zijn dat ze wat geld missen omdat ze afgeluisterd worden.
of het leger natuurlijk!

[johnkeates]

Als je als leger met cheap ass technologie gaat werken, ga je echt geen dure crypto engines kopen, en als je veilig gaat werken, dan ga je echt geen mobiele telefoons gebruiken.

[Herko_ter_Horst]

Ik neem aan dat beide partijen zo'n kaartje moeten hebben om dit te laten werken? Leuk dus voor specifieke gevallen, maar niet in het algemeen.

[miw]

Het lijkt me zonder meer mogelijk om via een speciaal programmatje in een telefoon de spraakverbinding van een extra versleutelingslaag te voorzien. Via de spraakverbinding is dan ook wel een sessie sleutel op te zetten. Dat gezeur over elleptic curve is een beetje onnodig. Het belangrijkste vraag is of je een microSD kaart in staat is om een programma toe te voegen aan de GSM firmware. Als dat kan is het ook handig om te weten of de gebruiker daar nog toestemming voor moet verlenen. Ook handig is het om te weten of een dergelijke toepassing voor elke GSM telefoon beschikbaar is (via een VM ofzo) of dat er een speciale App is voor elk type telefoon.

[Centropy]

Ook al vind ik mij een normaal mens, en ik niets heb om te verbergen, is het toch fijn dat het er is, al is het alleen maar om wat macht weg te nemen bij Jusietiesie en de Telco's

Crime dudes vinden toch hun weg wel...

[chronoz]

Het kenmerkende is voor mij ook dus dat vooral de normale burger de dupe wordt van steeds minder privacy, meer censuur, e.d.

De criminelen worden daar echt niet mee aangepakt en kunnen zeker via het internet, heel makkelijk anoniem blijven.

Jammer dat niet vermeld staat of en wat de ontvanger nodig heeft om encrypted te kunnen bellen.

[Soldaatje]

Zou het niet handiger zijn om hier gewoon een App voor te gebruiken? Is wat flexibeler, of Skype?

[arjankoole]

crypto vergt nogal wat, een dedicated cryptografische chip voor dat werk is best belangerijk.

[Verwijderd]

Voorlopig kan elke willekeurige website op een Android toestel een SD kaart nog eenvoudig uitlezen

[Verwijderd]

Dat heeft geen invloed op de effectiviteit van de versleuteling van het telefoongesprek.