ETSI maakt radio-encryptiestandaard van nooddienstennetwerk C2000 openbaar

Standaardisatieorganisatie ETSI wil de cryptografische algoritmes van Tetra openbaar beschikbaar stellen. Tetra wordt onder meer gebruikt als radio-encryptiestandaard van het Nederlandse nooddienstennetwerk C2000.

Toen de eerste Tetra-algoritmes begin jaren negentig werden gemaakt, was het normaal om die algoritmes geheim te houden. Tegenwoordig is dat niet meer zo, schrijft ETSI, en worden ze juist openbaar beschikbaar gesteld zodat overheidsnetwerken en kritieke netwerken beschermd kunnen worden. Daarmee kunnen dergelijke algoritmes getoetst worden en kunnen eventuele problemen worden opgelost.

De standaardisatieorganisatie besloot daarom in oktober de cryptografische primitives openbaar beschikbaar te stellen. Dit volgde op een overleg waaraan ook overheden, fabrikanten en gebruikers meededen. ETSI organiseerde dit overleg nadat deze zomer Nederlandse beveiligingsonderzoekers diverse kwetsbaarheden hadden ontdekt in Tetra. Door de kwetsbaarheden is de encryptie 'binnen een minuut' te kraken en zijn man-in-the-middle-aanvallen mogelijk.

ETSI zegt nog niet wanneer de encryptiestandaarden openbaar beschikbaar worden gesteld. Ruim 120 landen gebruiken Tetra-netwerken voor draadloze communicatie. De Tetra-standaard zelf was al openbaar beschikbaar, alleen de encryptie niet.

Door Hayte Hugo

Redacteur

15-11-2023 • 10:49

49

Submitter: Monochrome

Reacties (49)

49
49
27
2
0
16
Wijzig sortering
Hoewel het misschien in eerste instantie raar klinkt om dingen over een encryptie standaard, gemaakt om gegevens te beveiligen en privé te houden, openbaar te maken; kan ik dit alleen maar aanmoedigen.

Het "Principe van Kerckhoffs" is hierbij erg belangrijk.
Een versleutelingssysteem moet veilig zijn zelfs als alle details van het systeem, behalve de sleutel, publiek bekend zijn.
Het "geheim" houden van het versleutelingssysteem geldt dan eerder als "Security through obscurity" wat als een slechte manier van beveiliging gezien wordt.
Voor de kenners is het een open deur, maar ik wil nog even toevoegen dat het Principe van Kerckhoffs geen manier is om dingen veiliger te maken. Kerckhoffs omschrijft een eigenschap en een gevolg. Als een algoritme echt veilig is, dan is het ook veilig als iedereen weet hoe het werkt. Je mag dat echter niet omdraaien, je kan op grond van het Principe van Kerckhoffs eigenlijk niet zeggen dat het niet veilig is als het niet openbaar is, of dat het veiliger wordt door het algoritme te openbaren.

Maar in praktijk worden algoritmes en code wel degelijk veiliger door ze te openbaren zodat iedereen mee kan kijken en fouten en zwakheden vinden. Sterker nog, encryptie en programmeren zijn zo moeilijk en vereisen zoveel verschillende specialiteiten dat het eigenlijk niemand lukt om dat foutloos te doen. Je moet wel samenwerken om alle fouten te vinden en op te lossen. Dat heeft alleen niks met Kerckhoffs te maken.

Er is nog een goede reden voor openbare encryptie: vertrouwen. We kunnen niet bewijzen dat algoritmes (of de implementatie daarvan) veilig zijn. De enige reden dat we er echt op vertrouwen is dat talloze experts jarenlang hebben geprobeerd om het kapot te maken en dat is niet gelukt. Dat kan alleen in het openbaar als je breed vertrouwen wil. Experts van de regering zullen altijd gewantrouwd worden door andere landen of politieke stromingen. Iedereen zal dat door z'n eigen experts moeten laten doen.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 18:19]

Ik ben absoluut geen kenner, maar is het signaal wat afgegeven wordt door het openbaar maken van cryptografische algoritmes ook niet belangrijk?

Een een bedrijf achter een veelgebruikt proprietary cryptografisch algoritme zal deze niet openbaren als er backdoors in zitten, of als men niet overtuigd is dat de encryptie niet makkelijk te doorbreken is. Het bedrijf verkleint haar mogelijkheden om haar agenda geheim te houden.

Heeft vertrouwen en veiligheid hier geen grote overlap? Met de bovenstaande logica zou je kunnen stellen dat encryptie die open source gemaakt wordt onmiddellijk als veiliger gezien kan worden. De algoritmes veranderen niet, maar door het signaal wat afgegeven wordt kom je meer te weten over de agenda van de ontwikkelaar.

Nu zou je kunnen zeggen, dit gaat om vertrouwen. Maar je zegt dat we niet kunnen bewijzen dat algoritmes en hun implementaties veilig kunnen zijn. Dus het lijkt me dat we veiligheid door middel van vertrouwen bedoelen als we het over veiligheid hebben. De objectieve veiligheid is immers niet bekend. En voor veiligheid gebaseerd op vertrouwen telt een signaal van transparantie mee.
Ik ben absoluut geen kenner, maar is het signaal wat afgegeven wordt door het openbaar maken van cryptografische algoritmes ook niet belangrijk?
Zeker, precies zoals je zegt, het is een duidelijk signaal dat de auteur er zelf vertrouwen in heeft. Dat gaat zelfs verder dan alleen de veiligheid, je geeft de wereld inzicht in de kwaliteit van je werk zonder de mogelijkheid om broddelwerk te verbergen.

Een beveiliging heeft weinig zin als je er geen vertrouwen in hebt. Door een combinatie van technische en theoretische redenen kunnen we nooit echt bewijzen dat encryptie veilig is. Sterker nog, je kan wel bewijzen dat alles te kraken is als je er maar genoeg tijd en moeite in wil steken. Net als bij een gewoon slot is het doel niet om een inbraak volledig onmogelijk te maken maar om de inbreker te vertragen. Het liefst zoveel te vertragen dat het geen zin heeft om het te proberen.

Om het beste slot te vinden organiseren we wedstrijden waarin de beste (digitale) slotenmakers proberen elkaars sloten open te breken. Door te kijken hoe dat gaat krijgen we een beeld van wat de sterke en zwakke punten van een bepaalde methode zijn. Maar uiteindelijk weet je het nooit zeker, het is altijd mogelijk dat er een gat is dat door iedereen over het hoofd is gezien. Hoe meer mensen het proberen hoe groter het vertrouwen is dat we in een bepaalde methode kunnen hebben. Als ze hun resultaten delen en samen werken is dat alleen maar beter. Daarom is het heel wenselijk om cryptografisch onderzoek in het openbaar te doen.
Een een bedrijf achter een veelgebruikt proprietary cryptografisch algoritme zal deze niet openbaren als er backdoors in zitten, of als men niet overtuigd is dat de encryptie niet makkelijk te doorbreken is.
In ieder geval geen backdoor dat door het bedrijf is aangebracht. Door de broncode openbaar te maken tonen ze dit niet alleen, maar hopen ze erop dat anderen eventuele niet opzettelijke backdoors vinden en de encryptie nog veiliger maken.
En voor veiligheid gebaseerd op vertrouwen telt een signaal van transparantie mee.
Helemaal mee eens.
Voor de kenners is het een open deur, maar ik wil nog even toevoegen dat het Principe van Kerckhoffs geen manier is om dingen veiliger te maken. Kerckhoffs omschrijft een eigenschap en een gevolg. Als een algoritme echt veilig is, dan is het ook veilig als iedereen weet hoe het werkt. Je mag dat echter niet omdraaien, je kan op grond van het Principe van Kerckhoffs eigenlijk niet zeggen dat het niet veilig is als het niet openbaar is, of dat het veiliger wordt door het algoritme te openbaren.

Maar in praktijk worden algoritmes en code wel degelijk veiliger door ze te openbaren zodat iedereen mee kan kijken en fouten en zwakheden vinden. Sterker nog, encryptie en programmeren zijn zo moeilijk en vereisen zoveel verschillende specialiteiten dat het eigenlijk niemand lukt om dat foutloos te doen. Je moet wel samenwerken om alle fouten te vinden en op te lossen. Dat heeft alleen niks met Kerckhoffs te maken.
In die zin is Kerckhoffs wel een voorwaarde voor veiligheid van een algoritme: als een algoritme niet publiekelijk beschikbaar is, kunnen cryptoanalysten het ook niet onderzoeken. En gedegen onderzoek is nodig om te kunnen concluderen dat het veilig is.
Dat klopt ook niet, want Tetra is momenteel niet openbaar, maar is toch onderzocht. Het kost alleen meer tijd dan wanneer de specificatie openbaar is...
Je mag dat echter niet omdraaien, je kan op grond van het Principe van Kerckhoffs eigenlijk niet zeggen dat het niet veilig is als het niet openbaar is, of dat het veiliger wordt door het algoritme te openbaren.
Dat lijkt me vooral afhangen van het feit dat als je iets niet kan bewijzen je er dus ook geen harde uitspraak over kan doen alsof het een zelfde uitkomst heeft. Daarom kan men bij geheim proberen te houden ook omgekeerd niet stellig beweren alsof dat veiliger is.

[Reactie gewijzigd door kodak op 22 juli 2024 18:19]

Ik zie het zo:
Overal worden fouten gemaakt. Ook in onze beveiliging zitten zeker fouten. Hoe meer mensen mee kijken hoe groter de kans dat ze tijdig gevonden en opgelost worden.

Het geheim houden van code maakt het een beetje moeilijker om fouten te vinden, maar niet heel veel. Het enige wat geheim wordt gehouden is immers de voor mensen makkelijk leesbare variant van de code. De machinecode is nog steeds gewoon leesbaar. Dat is wat moeilijker maar niet onmogelijk.

Eigenlijk is de vraag dus niet of de algortimes geheim worden gehouden, maar hoe makkelijk of moeilijk het is om de code te lezen. Mensen met voldoende motivatie vinden de fouten toch wel. Je weet dat de criminelen het gaan proberen. Dan zou je dus een som kunnen maken. Is de kans groter dat het openbare van de code helpt om een fout tijdig op te lossen of is de kans groter dat een crimineel een fout vindt die anders geheim was gebleven? Maar dat is niet het hele verhaal. Als een fout eenmaal gevonden is wil je die ook oplossen. Daarbij is het verschil tussen het wel of niet hebben van de broncode veel groter.

Openbaarheid maakt het een beetje makkelijker voor criminelen die op zoek zijn naar gaten, maar het voordeel voor de "good guys" hebben datzelfde voordeel. Beide partijen zoeken naar fouten en hebben dus min of meer hetzelfde voordeel.

Aan de andere kant is open code een enorm voordeel als je een probleem probeert op te lossen. Dat werkt alleen in het voordeel van de "good guys", de aanvallers hebben er niks aan want die proberen het gat helemaal niet te dichten. Het werkt meer in het voordel van de "good guys" omdat die het typisch meer moeten hebben veel mensen die er oppervlakkig naar kijken dan van een paar zeer gedreven criminelen die bereid zijn om zich er in vast te bijten.

Netto komt het er dus op neer dat open code beter is dan geheime code. Voor het vinden van gaten maakt het weinig uit maar bij het dichten van gaten is het verschil enorm.
Geheim houden is hooguit een poging. Of het nu een machine is dat de verwerking doet, teksten en beelden van het ontwerp zijn, communicatie van resultaten door de ether is, of menselijke betrokkenheid bij dit alles is, bij geen van deze omstandigheden is er ultime geheimhouding te garanderen. Er valt dus ook niet bij te stellen dat de geheimhouding dus maar voldoende is. Hooguit acceptabel op basis van andere omstandigheden van feiten en wensen. Het lijkt dus eerder een principe van zekerheid te zijn tegenover een onzekerheid. Het is dus maar net waar iemand meer waarde aan hecht.
Bor Coördinator Frontpage Admins / FP Powermod @milo52615 november 2023 11:38
Het "geheim" houden van het versleutelingssysteem geldt dan eerder als "Security through obscurity" wat als een slechte manier van beveiliging gezien wordt.
Een veel gehoord statement maar zo kort door de bocht is het niet. Uit je eigen aangehaalde bron:
Security through obscurity is een beginsel uit de beveiliging. Men beoogt daarmee beveiligingsrisico's te beperken door (de werking van) beveiligingsmaatregelen geheim te houden. De achterliggende gedachte is, dat als het beveiligingsmechanisme niet bekend is, de beveiliging moeilijk door derden kan worden doorbroken. Geheimhouding van de beveiligingsmethode mag nooit het enige beveiligingsmechanisme zijn.
Het geheimhouden van details kan een valide beschermingsmaatregel zijn mits je dit aanvult met andere maatregelen. Je kan dit breder doortrekken. Zo zijn datacentra vaak niet als zodanig aangemerkt, wordt vaak niet zeer zichtbaar aangegeven waar patchruimten zijn etc. Wanneer het aankomt op cryptografiche algoritmen heeft het openbaren zeker voordelen maar om nu te stellen "security by obscurity is bad" ...

[Reactie gewijzigd door Bor op 22 juli 2024 18:19]

zichtbaar aangegeven waar patchruimten zijn etc. Wanneer het aankomt op cryptografiche algoritmen heeft het openbaren zeker voordelen maar om nu te stellen "security by obscurity is bad" ...
Dat ben ik met je eens. Zelfs als ik mijn waardevolle bezittingen in een goede kluis stop, vind ik het niet nodig te openbaren welk merk het is en waar deze staat. Maar bij protocollen als C2000 worden de protocollen toch vroeg of laat achterhaald, dus kun je er bij inrichting van het systeem beter vanuit gaan dat de algoritmes algemeen bekend zijn.

[Reactie gewijzigd door 84hannes op 22 juli 2024 18:19]

Het grootste probleem van 'geheimhouden' zit meer in het 'algemene' geheimhouden. Wat ik bedoel is: ik hoef niet te weten wat 84hannes voor een kluis heeft, maar als de kluis fabrikanten besluiten (middels een NDA oid) om alle onderzoek naar de veiligheid te verbieden dan is er wel een probleem. Dankzij bijv. the LockPickingLaywer op youtube weet ik dat Masterlock sloten voornamelijk markteting gedreven sloten zijn en niet heel goed. Dat is nuttige informatie. Dat ik niet weet welke kluis 84hannes heeft en of dit een masterlock kluis is is nuttige security. Zo ook met crypto: het algoritme mag nooit geheim zijn. Welke algoritme waar zit is al minder belangrijk om te weten. Je wil vooral dat onderzoekers zonder juridische obstakels iets kunnen onderzoeken en vanuit dat oogpunt is security through obscurity geen goed idee. De toepassing van een bepaalde techniek in een bepaalde context niet delen kan inderdaad een onderdeel van het security model zijn.
Voor alles geldt dat je goed na moet denken wat je openbaar maakt en wat niet.
Bij encryptie kan je de methode heel goed openbaar maken, maar de sleutel niet. Voor datacentra geld dat ze fysiek aangevallen kunnen worden als bekend is waar ze staan en ook nog eens goed herkenbaar zijn.
Zo mag je mijn rekening nummers best weten, maar zal ik je de pin-codes nooit geven.
Dit kan je ook zien dat alle groot gebruikte encryptie standaarden(AES, RSA, ED25519) open zijn, in mijn mening maakt dit de security nog hoger dan als ze niet open standaarden zijn worden geweest want het maakt het zodat veel meer cryptographise experts het kunnen analyzeren.

Toen er bijvoorbeeld een alternatief die sterker was nodig was voor DES(of Triple DES in die tijd) was er door het NIST in America een grote wedstrijd gedaan waar allemaal organisaties een cryptographise methode mochten opleveren, en na dit werden ze allemaal publiek gemaakt en was het idee dat iedereen hem mocht proberen te breken, waarna uiteindelijk een selectie werdt gemaakt.

En ik ben het met je eens dat het Principe van Kerckhoffs heel erg luid bij dit, alleen zie ik nog altijd dat mensen het raar vinden dat encryptie protocollen publiek worden gemaakt
Toch vraag ik me nog wel af of AES echt niet gekraakt kan worden door de Amerikaanse inlichtingen diensten voornamelijk dan de NSA.

Voor DES bleek dacht ik ook later dat de NSA het veel eerder konden lezen dan dat algemeen bekend was. Door speciale hardware matige decoders.

Maar gezien AES openbaar is en het nog steeds echt gekraakt is. Wordt deze kans wel steeds kleiner. Ook bij het Snowden lek bleek het nog veilig.
Volgens Wikipedia heeft de NSA er voor gezorgd dat DES zwakker werd dan het oorspronkelijke ontwerp. Verder waren delen van DES niet openbaar gemaakt.
Dual_EC_DRBG is nog zo'n voorbeeld waar de NSA wat obscurity toegevoegd heeft.
Ook bij AES is er wat gewijzigd dacht ik ten opzichte van het eerste Rijndael concept. Ik heb ooit nog eens een AES/Rijndael encrypter en decrypter geschreven als een school opdracht ergens rond 2002 of 2003. Ook toen waren hier al discussies over. Die wijziging in Rijndael was zeer waarschijnlijk een verbetering. Maar sommige twijfelden.

Bij DES in het ondertussen inderdaad aangetoond dat de NSA dit wel kon kraken en ook eerder dan de rest en zwakker had gemaakt.
Dus in theorie heb je gelijk maar in de praktijk is het onwaarschijnlijk. Het probleem met DES is dat we wisten dat het in de nabije toekomst zou kunnen worden gekraakt, maar dit was niet door(voor het grootste deel) een vulnerability in DES maar meer omdat de computatie capaciteit zo erg was verhoogd. Er waren well een paar vulnerabilities in TDES zelf(Had attacks zoals block collision attacks als er maar genoeg encrypted data was), maar het werdt mogelijk gemaakt door de rapid evolutie van computionale capaciteit die zo rapid was dat de standaarden die waren gemaakt helemaal niet voorbereid waren voor zulke toename in capaciteit.

DES was uitgekomen in 1981. De supercomputer die net uitkwam na Triple-DES is de cray2 die 1.9Gigaflops aan computing capaciteit heeft, voor reference toen AES uit kwam in 2000(toen was het gestandaardiseerd) was 4.94Teraflops dat is een x2600 keer zo veel computing capaciteit.

Volgens het NIST had TDES maar 80 bits van security in de praktijk, wat in de moderne tijd helemaal niet genoeg is en daarom kan je nu ook met een goed genoege GPU een TDES cipher in een tijdje kraken.

Het grotere probleem met encryptie standaarden zijn side channel attacks, waar het probleem niet zit in de standaard zelf zit maar in de implementatie daarvan, hier kan je zeker well problemen vinden(En zijn er ook geweest in bijvoorbeeld 2005 met OpenSSL, en meerde andere timing attacks sinds dien).

AES is ook niet zwak tegen quantam computers want het is een symetric encryptie inplaats van asymetric waar een grote zwakte ligt tegenover super computers(Maar er is nu well een race om nieuwe asymetric encryptie te vinden die quantam resistant is), het is well zwakker dan tegen reguliere computer waardoor het soms wordt geargumenteerd dat AES-128 en AES-192 "insecure" zijn als je kijkt naar de lange termijn, maar AES-256 niet.

* En als laatste was er met DES een beetje schimigheid met hoe hij werdt gekozen omdat ze na consultatie met de NSA hebben ze de standaard een klein beetje aangepast zodat hij een bepaalde aanval sterker was, maar zwakker tegen een brute force aanval.

[Reactie gewijzigd door Stetsed op 22 juli 2024 18:19]

Eens met de rest van je verhaal. Maar bij DES had je in 1998 al gespecialiseerde hardware die DES binnen 56 uur kon kraken en die ongeveer $250,000 koste. Deze wedstrijd was toen georganiseerd door RSA. En eigenlijk bedoelt om aan te tonen dat de NSA en waarschijnlijk andere staten ook DES konden kraken.
https://en.wikipedia.org/wiki/EFF_DES_cracker

DES bevat bit manipulatie en verwisselingen die traag werken op een CPU. Maar die je snel kunt uitvoeren op een dedicated chip. Of later en wat langzamer maar veel goedkoper op een FPGA. Ik heb geen goed idee over de performance van een GPU hiervoor. Waar die is waarschijnlijk ook al veel sneller dan een CPU voor dit werk.
Dat kan ik alleen maar met je eens zijn.

Het enig geheime element in een encryptie setup moet de sleutel zijn. De rest moet om redenen die je noemt open zijn.
Let op dat Kerckhoffs' principe vanuit de theorie is gemaakt. Hij kijkt voornamelijk naar de pure definitie (modellen) van encryptiestandaarden.

In de praktijk moet je ook side-channel attacks voorkomen. Daarvoor is het bijvoorbeeld belangrijk dat de bron voor willekeurige data onvoorspelbaar genoeg is.

Daarom spreek ik liever over encryptiestandaard in deze, en niet over 'encryptie setup'. Voor een standaard mag je uitgaan van aannames over zaken die buiten scope liggen (zoals een perfecte RNG). In de praktijk kan je dat beter niet doen. ;)

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:19]

zoals een professor van mij zei: niets is zo praktisch als een goede theorie.
@Hayte TETRA zoals in NL wordt gebruikt, gebruikt de 80bit key en niet de 32 bit key. De kwetsbaarheid waardoor Tetra binnen een minuut is te kraken zit dus niet in C2000, zie ook de reacties op het artikel waar je naar linkt.
De onderzoekers zeggen toch juist dat die 80bit-key heimelijk wordt omgezet naar 32bit, waardoor het ook kwetsbaar is voor de 32bit-aanval?
Citaat: "Die zwakke encryptie zit in slechts een van de encryptielagen van Tetra. Dat heeft vier van zulke lagen: TEA1 tot en met TEA4. TEA1 is bedoeld voor de versleuteling van toepassingen in commercieel beschikbare apparatuur. TEA2 en TEA3 worden vooral gebruikt door toepassingen binnen bijvoorbeeld de politie en noodhulpdiensten. TEA2 is het encryptieniveau dat in het Nederlandse C2000-communicatiesysteem wordt gebruikt."

@Monochrome legt het verder uit in de thread: Monochrome in 'Onderzoekers vinden kwetsbaarheden in radio-encryptiestandaard van C2000' zie
"TEA1 is wel degelijk gebackdoored, gezien TEA1 een 80-bits key gebruikt. Het geheime TEA1 algoritme comprimeert eerst die key tot 32 bits voordat er keystream voor encryptie/decryptie gegenereerd wordt."
en
"C2000 is een netwerk, geen encryptiealgoritme. C2000 gebruikt het TEA2 encryptiealgoritme."
Ah ja, helder. Ik heb het artikel aangepast, dank voor het aangeven :)
Dit is ook de reden waarom je als je een TEA2 portofoon hebt, je een apart simkaartje krijgt. Daarmee wordt de encryptie ontsloten. In TEA1 portofoons heb je in principe die sim niet nodig.
De onderzoekers zeggen toch juist dat die 80bit-key heimelijk wordt omgezet naar 32bit, waardoor het ook kwetsbaar is voor de 32bit-aanval?
Dat is belachelijk... 80bit in 32bit omzetten, waarom doen ze dat? Waarschijnlijk gebruiken ze nog steeds oude machines, anders was omzetting (compatible maken) niet nodig???
zoals eerder al opgemerkt, in NL gebruiken we dat niet voor C2000.
Dus storm, glas water?
Daarnaast, je praat wel over een systeem dat 40 jaar geleden is bedacht.
De mobiele computing kracht was toen net iets meer dan een aardappel, en de gemiddelde "mobiele" telefoon was ter grootte van een halve "schoenendoos".
Even een vergelijking van wat toen "normaal" was, versus een I Phone:
https://www.nu.nl/mobiel/...smartphones-jaren-90.html
Midnight Blue toont hier wat verdieping:
https://media.ccc.de/v/ca...all_cops_are_broadcasting - All cops are broadcasting
Obtaining the secret TETRA primitives after decades in the shadows
super ontwikkeling, mooi om te zien dat open-source en overheid steeds vaker samen gaan.
zie ook: https://www.digitaleoverh...erpen/open-source/beleid/

dat gezegd hebben, wanneer ik met een odt bestand aankom zetten, wordt dat vaak geweigerd. of type bestand wordt niet geaccepteerd om te uploaden.

maar goed, beetje bij beetje 'komen we er wel'
ODF is gewoon de strandaard binnen de overheid: https://www.forumstandaardisatie.nl/open-standaarden/verplicht

Beetje jammer dat ze ODT dan weigeren. Klinkt als ontwetendheid gezien Word het al jaren ondersteund...
Ik weet niet of het wel slim is om nu nog dit openbaar te maken.
Het is al zo lek als een mandje.
Maar vervangen is ook niet zomaar gedaan.
Dus nu openbaar maken, kan wel zorgen voor veel meer hacks....
Meer hacks? Ja, maar dan weet men ook beter wat er opgelost (zou) moet(en) worden.
De situatie wordt hier niet erger van. Dat dit encryptie systeem voor geen meter werkt, staat op zich. Een encryptiesysteem moet nog steeds veilig zijn wanneer je exact weet hoe het werkt. Het is anders geen encryptie, maar gewoon een slecht bewaard geheim.

Het is nu lek, dus of er nou nog meer omzeilingen gevonden worden maakt niet meer uit.

Wat helpt, is de problemen oplossen of overstappen op iets anders.

[Reactie gewijzigd door youridv1 op 22 juli 2024 18:19]

Maar vervangen is ook niet zomaar gedaan.
Als dat waar is, dan is dat een flinke een design-error... !
Juist het encryptiesysteem moet je eenvoudig kunnen updaten. By-design moet je er altijd vanuit gaan dat je encryptie gebroken wordt en je welk eens een nieuwe versie nodig hebt.
Ik verwacht, juist omdat het zo oud is, dat het al lang niet meer geheim is en bekend bij meerdere onwenselijke instanties. Nu is de hoop dat ze snel zaken ontdekken en patchen als er echt wat kwalijks in zit.

Dit is natuurlijk grootschalig genoeg dat je mensen krijgt die meekijken. Ik zou onze software niet zo snel open sourcen, want dat heeft geen community die profijt heeft van de verbeteringen, en dan stel je het wel primair bloot aan de buitenwereld om fouten te vinden en vooral niet te melden.
Rogues are very keen in their profession, and know already much more than we can teach them.
- Alfred Charles Hobbs, 1853
Daarmee kunnen dergelijke algoritmes getoetst worden en kunnen eventuele problemen worden opgelost.
Het openstellen heeft natuurlijk alleen zin als problemen die worden gevonden ook snel kunnen worden opgelost. Als de encryptie volledig zit ingebakken in de oplossing, en niet makkelijk aangepast kan worden zet je alleen maar de deur wagenwijd open, terwijl je eigenlijk het slot zou willen vernieuwen...
Dat het binnen een minuut te kraken valt maakt het niet onbruikbaar, echt minder geschikt voor bepaalde zaken.

[Reactie gewijzigd door hachee op 22 juli 2024 18:19]

Daarmee kunnen dergelijke algoritmes getoetst worden en kunnen eventuele problemen worden opgelost.
Ik begrijp de kern niet van deze statement. Closed source algoritmes kunnen vast ook intern getoetst worden en problemen ervan opgelost worden. Bedoel je nou dat open source code beter getoetst kan worden door een groter publiek? En dat problemen sneller opgelost kunnen worden door dat groter publiek?
Een systeem wat binnen een minuut te kraken is èn vatbaar is voor mitm aanvallen. Hoezo is dit nog in gebruik?
Her hoofddoel van het systeem is niet dat het niet af te luisteren is, het hoofddoel is communicatie.

Ik weet nog dat je vroeger, voor de komst van P2000, “politiescanners” had waar mensen met sensatiezucht naar luisterden omdat alles analoog en onbeveiligd de ether in ging. Konden ze op de fiets springen om naar de plaatselijke brand te kijken. Het overgrote deel van de wereld zal dit nog steeds analoog en onbeveiligd doen.

En voor 99% van de communicatie maakt dat ook niet uit. Dat de brandweer op een locatie om twee extra ambulances vraagt mag iedereen best horen. Sterker nog, hulpdiensten verplaatsen zich vaak met gillende sirene dus hun aanwezigheid is allesbehalve geheim.

Er wordt gewerkt aan een nieuw systeem dat dit, en een aantal andere problemen, niet zou hebben maar dat is nog geen reden om dan maar helemaal te stoppen met Tetra te gebruiken.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 18:19]

Het zijn natuurlijk niet alleen mensen met sensatiezucht. Als ik koper zou stelen langs het spoor, is het bijzonder nuttig om te weten óf de politie al iets van me weet, en zo ja, hoe lang het duurt voordat ze ter plaatse zijn. Zulke info moet gewoon goed beveiligd zijn, anders hebben serieuze criminelen zo apparatuur om het af te gaan luisteren.
Her hoofddoel van het systeem is niet dat het niet af te luisteren is, het hoofddoel is communicatie.
Onder "kraken" kun je natuurlijk ook rekenen dat iemand er op inbreekt die er niets te zoeken heeft en dus dingen gaat lopen zenden die er niet horen.
Ik weet niet welke drogredenaties je hier allemaal gebruikt, maar 'vroeger' is natuurlijk nooit een valide argument. En iets een hoofddoel noemen is lekker makkelijk als je daarmee alle andere eisen naast je neer kan leggen.

Die 99% is daarom ook te makkelijk, je kan niet bepalen welk bericht wanneer wel tot de 1% hoort. Het is net als encryptie met een achterdeur waar we hier al vaak genoeg gevoerd hebben.

Maargoed, mijn punt is dat je tegenwoordig op een telefoon van een paar tientjes wel onkraakbare encryptie hebt en apps waar je mee kan (video)bellen, locatie en weet ik veel wat nog meer kan delen - allemaal vroeger niet mogelijk maar zaken die letterlijk op verschillende manieren bij kunnen dragen aan het redden van levens. Het lijkt mij er op dat de hulpdiensten op dit moment beter af zouden zijn met een consumenten-app als Whatsapp/Telegram/Signal dan dit systeem wat al 20+ jaar voor problemen zorgt.

[Reactie gewijzigd door Alxndr op 22 juli 2024 18:19]

Ik wil niet zeggen dat het systeem volstrekt probleemloos is zonder enige vorm van beveiliging. Het is zeker nuttig dat een opvolger betere encryptie heeft.

Ik wil alleen zeggen dat een beetje proportionaliteit op zijn plaats is. Er is geen reden om per direct een systeem uit te schakelen en te vervangen door een consumentendienst (gerund door een buitenlandse privacyschender) waar diverse andere problemen mee zijn terwijl het hoofddoel toch vooral gewoon vrij basale communicatie is waar geheimhouding niet in de top drie vereisten staat.
Mooie ontwikkeling!

Op dit item kan niet meer gereageerd worden.