Goed opgemerkt, en inderdaad geen reclame voor de escrow partij .

Ik wil wel opmerken dat voor MD5 nog steeds _slechts_ een collision vinden mogelijk is.
Een kwaadwillende _bron_ kan inderdaad twee versies produceren met dezelfde MD5 hash .

Een kwaadwillende *derde* kan geen versie produceren met dezelfde MD5 hash als de "echte" versie waar de derde geen controle over heeft.

Het is in dit scenario dus alleen MinVWS die de mogelijkheid had/heeft om twee versies te produceren, één door de escrow partij te laten bekijken, en een tweede die anders is maar dezelfde MD5 hash heeft .

Inderdaad, en dat is toch ietwat zorgwekkend. Nou zou de soep wel niet zo heet
gegeten worden, maar het is wel echt slecht voor de beeldvorming. Is er ook maar
iets van een valide reden om MD5 te kiezen?

Nee, ik kan er geen valide reden voor verzinnen bij dit gebruik. Dat wil niet zeggen dat het kwaadwillend is en bedoeld om VWS zo'n optie te geven .

Ik denk dat het puur 'gewoonte' is bij de Escrow partij dat ze MD5 "altijd" als hash gebruiken om zeker te zijn dat files niet gemuteerd zijn. (en het voldoet prima als je threat-model alleen een kwaadwillende buitenstaander is, of gewoon transport corruptie)

Erik merkt terecht op dat het een indicatie is dat ze _security_ ontwikkelingen gemist hebben ;
Net als de slorigheid in het door elkaar halen van de app namen.

Dat maakt inderdaad dat het met de bruikbaarheid van MD5 voor dit doel wel meevalt. Aan de andere kant is het belachelijk dat niet een veel sterker hashalgoritme is gebruikt, dat is net zo makkelijk beschikbaar als MD5.

De gedachte die dit bij me oproept is dat het er bij Escrow Alliance of bij hun softwareleverancier er net zo aan toegaat als bij zoveel andere bedrijven: een wijziging krijgt pas prioriteit als het echt begint te knellen, dus zo lang MD5 als goed genoeg kan worden beschouwd wordt ieder initiatief om deze kleine verandering door te voeren de pas afgesneden. Want iets aanpassen zonder acute noodzaak wordt als een overbodige kostenpost gezien, en kosten drukken heeft altijd een hoge prioriteit. Als dat erachter zit is het verwant aan de bevoorradingsproblemen die de wereld onder invloed van de pandemie heeft, men "optimaliseert" verder en verder zonder de kwetsbaarheden die dat oplevert in te zien.

In dit geval levert MD5 denk ik voor deze toepassing nog geen acute kwetsbaarheid op, maar met MD5 zit je vrijwel zeker wel veel dichter bij het moment dat het probleem acuut wordt dan bij sterkere algoritmes. Dat levert een risico op, niet alleen door MD5 zelf maar ook door de slechte publiciteit die het kan opleveren als mensen er vragen over gaan stellen. Dat gebeurt nu op dit forum, het kan als het eenmaal is opgemerkt ook opeens een kamervraag worden. Het antwoord daarop zal dan zijn dat er nog geen indicaties zijn dat MD5 voor dit doel niet meer voldoet, maar dat neemt niet weg dat men daarmee etaleert kennelijk zelfs geen kleinigheid te willen investeren in het voorkomen van risico's. Dan laat men zien dat kwaliteit iets is voor verkooppraatjes maar niet om daadwerkelijk te leveren. Dat beeld klopt weer met het door elkaar halen van de twee apps, zoals Erik ook constateerde.

Hallo Erik. Je weet vast wat Key escrow is. Dat is een manier voor een overheid om als derde partij bij een conversatie tussen Alice en Bob te kunnen.

Erg ongelukkig dit allemaal. Is het naïviteit of boze opzet?

Nog iets, waarom zou je de client verzwakken als de server controleren veel interessanter is? Je wilt niet dat er met de client gerommeld kan worden, door wie dan ook. Dat leidt tot onbetrouwbare data. Of is de CoronaMelder App een backdoor voor iets anders, wat niets te maken heeft met Corona? En waarom zou een overheid dat willen?

Wie kiest een naam als Escrow Alliance als daar zoveel negativiteit omheen hangt?

Oneens.

VWS heeft naar verluidt als doel het wekken van vertrouwen bij Nederlanders dat de sources voor apps in de stores geheel overeenkomen met de (welliswaar met vertraging) gepubliceerde sources. Daarvoor gebruikt VWS een derde partij (TTP) die door ons, Nederlanders, vertrouwd zou moeten worden (en betaalt die partij van ons belastinggeld).

Risico: wij kunnen niet 100% uitsluiten dat er, naast de gepubliceerde sources, twee sets private sources bestaan: een goedaardige en een kwaadaardige (van die laatste hoeven de verantwoordelijken bij VWS niets te weten, het kan een initiatief zijn van een of meer ontwikkelaars met een extra agenda).

Een voorbeeld van een probleem: wij weten niet wat de relatie is tussen de opdrachtgever en de TTP; misschien werkt bijvoorbeeld een vriendje of een famielid van één van de ontwikkelaars bij die TTP.

Het volgende scenario is dan denkbaar: de kwaadaardige ontwikkelaar maakt twee zip-bestanden, zowel van de goedaardige als de kwaadaardige sources. Vervolgens manipuleert hij beide zip-bestanden zodanig, dat deze dezelfde MD5 hash opleveren (bijv. door het toevoegen van een dummy binair bestand dat niet gebruikt wordt tijdens de build).

Vervolgens stuurt hij de kwaadaardige zip naar de TTP, die daar een app van bouwt, vaststelt dat deze identiek is aan de app in de corresponderende play store, de zip-file archiveert als bewijs en de MD5 hash daarvan opneemt in de rapportage. Daarna laat de kwaadaardige ontwikkelaar de kwaadaardige zip door diens vriendje bij de TTP vervangen door de goedaardige, en publiceert de goedaardige sources. Mocht het later tot een dispuut komen, dan kan "bewezen" worden dat de sources in de door de TTP gearchiveerde zip-file zijn gebruikt voor de app in de store; immers de MD5 hash klopt.

Is dit een realistisch scenario? Nauwelijks.

Maar juist als je vertrouwen wilt wekken (het enige doel van het inhuren van zo'n TTP), is het essentieel dat alles zo goed mogelijk voor elkaar is. Blunderen met app-namen en gekraakte hash-algoritmes vind ik dan uiterst schadelijk voor het gevraagde vertrouwen. De hele exercitie is zo verspilling van belastinggeld. Sterker, sommigen zou kunnen denken dat VWS iets te verbergen heeft (ik doe dat overigens niet) en daarom zo'n flutpartij inhuurt.

Als je zo'n proces optuigt, doe het dan goed.

Sorry hoor maar dat is bullshit. Ik weet wel dat het hip is om dat te roepen maar het blijft bullshit.
Zeker als het bestand wat je beveiligt ook nog een andere vorm van integriteitcontrole heeft (dwz het is sourcecode die
wel moet compileren en die bij doorlezen geen rare bagger in comments laat zien, of het is bijvoorbeeld een zipfile die
correct uitpakt) dan is dit zeker niet te doen.
Die paar scenarios waarin het gelukt is die berusten op de aanwezigheid van grote hoeveelheden onbelangrijke data
in het bestand, en het feit dat er niemand naar het bestand zelf kijkt.
En zelfs dan nog was het niet "relatief eenvoudig" maar juist relatief moeilijk.
Als je maar lang genoeg eisen blijft stellen aan het algorithme dan is IEDERE hash slecht, immers de lengte van de
hash is (veel) kleiner dan die van het sourcebestand, dus er is ALTIJD een heeveel:1 mapping van bestanden naar hashes.

Maar escrow heeft dan juist weer een positieve connotatie.

https://www.investopedia.com/terms/e/escrow.asp

Typisch een oogkleppen nerd , kent maar één context voor de term escrow en hangt daar een hele samenzwering aan op.

De term escrow is algemener , ouder, en neutraler dan het besmette concept 'key escrow' .

Het is algemeen concept van een derde partij die dingen in bewaring heeft en vrij kan geven onder voorwaarden.

Als je later groot bent en misschien eens een huis gaat kopen betaal je via de 'derdengelden rekening van de notaris' .
Ook dat is escrow - in het Nederlands .
Jij hebt betaald - dat garandeert de notaris naar de verkoper, en de notaris geeft het geld vrij als de verkoper geleverd heeft, dat is de garantie naar jou als koper .


In wat specifieke situaties kan een klant van een leverancier vragen om de source van de cruciale software door een escrow partij te laten bewaren - zodat de klant erover kan beschikken als de leverancier omvalt .
Omdat de software zelf erg bedrijfsgeheim is wil de leverancier die - in de normale situatie - niet aan de klant geven .

https://en.wikipedia.org/wiki/Escrow voor allerlei transactie situaties waarin escrow een rol kan spelen.

"key escrow" was maar één variant van het begrip met inderdaad in security kringen een negatieve connotatie.


Iedereen die zaken doet met professionals die weten wat escrow betekent.

Over het feit dat het hier over een .zip bestand gaat waarover de MD5 hash wordt berekend:
https://datatracker.ietf.org/doc/html/rfc3385#section-10

CRC-32 in .zip is dus niet bedoeld voor cryptografische toepassingen en kan aangepast worden door degene die de .zip file heeft aangemaakt.

Het is wel een beetje zuur - dan heb je besloten dat je graag een extra stempel wilt hebben dat alles betrouwbaar is, huur je daar een professionele partij voor in , en moet je *alsnog* hun werk gaan zitten controleren of de boel zelf voorkauwen .

Ik vind het erg te prijzen _dat_ ze source publiceren, en dan ook nog een TTP inzetten voor de zo goed mogelijke garantie dat de build-source en de gepubliceerde source dezelfde zijn .

Ergens in de VWS organisatie leeft dan wel het begrip dat vertrouwen in deze dingen niet een gegeven is, maar bewezen en verdiend moet worden.

Alleen zo jammer dat ze dan , zo lijkt het, een beun de haas voor die ttp rol getroffen hebben.

En inderdaad,op dit specifieke punt(je) zou het zo makkelijk geweest zijn om een betere hash, of meteen een stuk of drie hashes te publiceren .
(de downloadable images van diverse linux distro's hebben vaak een aantal hashes ter controle. Technisch zou 'één goede' voldoende zijn, maar de gebruikers hebben gewoon niet altijd een hash programma bij de hand dat óók de beste hash support .)

Wat een bizarre reactie op deze site, notabene onder "security professionals". Ik schat de kans in als zeer klein, maar misschien wil je toch wat van mij aannemen en er wijzer van worden.

In 2006 hebben Benne de Weger et al laten zien dat je twee verschillende x.509 certificaten kunt maken met dezelfde (van MD5 gebruikmakende) signature. Die bestanden zijn 825 bytes groot. Zie https://www.win.tue.nl/~bdeweger/CollidingCertificates/. Meer info in https://www.win.tue.nl/hashclash/rogue-ca/.

Juist in een zip-bestand is het simpel om een willekeurig bestand toe te voegen waar bijv. een make file niet naar verwijst. Dan hoef je niet eens (bekende) trucs uit te halen zoals twee bestanden met dezelfde naam, bestanden met namen met illegale karakters of simpelweg achteraan of op een specifieke plaats in de file geplakte data. Veel bestandsformaten bieden namelijk de (soms onbedoelde) mogelijkheid om bepaalde metadata toe toe voegen (soms nodig voor specifieke besturingssystemen, zoals de klassieke MacOS resource forks). Ook Microsofts Authenticode bestanden kunnen nog steeds worden gemanipuleerd doordat niet alle bytes in de file (exclusief de signature en certificaten) in de berekening van de hash worden meegenomen.

Dat er collissions bestaan is inderdaad meestal een feit. Echter, bij een niet gekraakte cryptografische hash zijn er sterke aanwijzingen dat het, met onze huidige kennis en computers, binnen afzienbare tijd rekenkundig onmogelijk is om collisions te vinden. Bovendien moet niemand gepubliceerd hebben dat ze toch te vinden zijn; anders wordt zo'n hash als gekraakt beschouwd en hoort niet meer te worden gebruikt.

Zonder PKI was het internet enorm veel kwetsbaarder dan nu het geval is. Betrouwbare cryptografische hashes zijn daarbij een essentiële bouwsteen. Er zijn vele van dat soort hashes waar cryptografen zich op hebben blindgestaard, maar die desondanks niet gebroken zijn. Gelukkig maar.

De meeste zijn gratis in te zetten. Behalve laksheid zie ik geen enkele reden om, voor welke toepassing dan ook, MD5 te blijven gebruiken.

Met name indien vooraf gepland misbruik een risico vormt, zoals in dit specifieke geval (en bij digitale certificaten), is het idioot om verificatie op MD5 te baseren.