Microsoft waarschuwt voor toename diefstal van certificaten

Microsoft waarschuwt op zijn Threat Research & Response Blog voor een recente toename van het gebruik van gestolen certificaten om diverse soorten malware legitiem te doen lijken. Systeembeheerders zouden hun privésleutels beter moeten afschermen.

In de blogposting wijzen de beveiligingsonderzoekers van Microsoft onder andere op de Win32/Winwebsec-malware. Deze scarewarevariant is onlangs teruggekeerd in een nieuwe vorm en doet zich voor als een antivirustool. Winwebsec is ondertekend met diverse certificaten om de malware op een legitieme applicatie te laten lijken. Volgens Microsoft hebben de makers daarbij gebruikgemaakt van de certificaten van in totaal twaalf softwareontwikkelaars. Ook de malware met de namen FakePav en Ursnif heeft onlangs van deze aanvalstactiek gebruikgemaakt, waardoor de kans op succes voor de aanvallers groter is.

Volgens Microsoft was er na het ontdekken van Stuxnet, de malware die met tal van gestolen certificaten werkte, relatief weinig gebruikgemaakt van gestolen certificaten; in de meeste gevallen zouden malwaremakers zelf tegen betaling certificaten hebben gekocht bij certificaatverstrekkers. In de laatste maanden lijkt er volgens de softwaregigant echter sprake te zijn van een opleving van het gebruik van gestolen certificaten. Ook Nederlandse softwareontwikkelaars hebben te maken met diefstal; vorige maand kregen kwaadwillenden het certificaat van een ingenieursbureau uit Enschede in handen.

Microsoft benadrukt dat softwareontwikkelaars extra voorzorgen moeten nemen om de privésleutels die nodig zijn voor het ondertekenen van een certificaat goed te beschermen. Zo zouden dergelijke sleutels bewaard moeten worden op hardwarematig beveiligde opslagsystemen, zoals smartcards of usb-tokens. Niet alleen is een bedrijf dat zijn sleutels kwijtraakt volgens Microsoft veel geld kwijt om de directe schade te herstellen, ook het imago van een onderneming kan een flinke deuk oplopen.

Reacties (33)

Dit is vooral nadeling voor Microsoft's security model. Ondertekende software kan van alles ongevraagd doen, en zelfs in kernel space gewoon geladen worden zonder speciale vragen te stellen.

Dus stel dat een certificaat gejat wordt, dan kan je daar je favoriete rootkit mee ondertekenen en zal windows geen vragen stellen.

Heeft niets met het Microsoft security model an sich te maken. Apple en Linux zijn net zo goed vatbaar voor deze aanval.

Op een standaard Windows PC, staat signing verificatie uit voor veel onderdelen van het OS. Ik geloof dat enkel voor drivers en bepaalde andere kernel onderdelen het standaard aan staat, maar ik laat me graag corrigeren/aanvullen. Hoe dan ook, juist omdat mensen op Windows verwachten dat ze vanalles van verschillende bronnen kunnen draaien staat de signing verificatie grotendeels uit op een concumenten PC.

Zet je dat echter aan (zoals op Windows RT standaard staat, en bedrijven die met gevoelige gegevens werken kunenn doen), kun je enkel software draaien, die én ondertekend is, én waarvan het root-certificaat in de betreffende machine geinstalleerd is.

Dat is ook de kern hier. Als ik een bedrijf ben dat met gevoelige gevens werk, zet ik die beveiliging aan en zorg ik dat ik enkel software van Microsoft en laten we zeggen bedrijf A, B en C accepteer. Geinstalleerde shareware van een werknemer draait dan gewoon niet. Echter professionele hackers (vaak in overheidsdienst of concurerend bedrijf) proberen dan het certificaat van bedrijf B te stelen, en hun eigen malware te signen.

Een andere minder zware variant is installers. Installers van een bedrijf X, controleren vaak de hantekening bij installeren van updates. Zodat ze niet per ongeluk malware installeren mocht bijvoorbeeld een man-in-the-middle het netwerk kanaal binnengedrongen is. Immers je moet er niet aan denken dat Windows Update or Adobe Updater gehacked wordt. Echter dit is wat kan gebeuren. Als men het certifciaat steelt en dan netwerkverkeer weet om te leiden, kan men malware installeren via updaters, zelfs als de gebruiker zelf geen rotzooi installeerd.

Het onderliggende OS maakt hierin dus geen bal uit.

Vanaf Windows Vista x64 kan je alleen maar kernel-space software laten draaien als ze digitaal ondertekend zijn. De enige manier om dat uit te zetten is de BCD aanpassen en TESTSIGNING aan zetten zodat het OS ook niet-ondertekende software toestaat. Dan krijg je een watermerk op je desktop met "Test Mode" en je windows versie en buildnummer.

Wat betekent dit? Stel dat je een rootkit hebt, en je in kernel-space wil draaien, dan moet je dus een geldig digitaal certificaat hebben, of testsigning aan zetten. Er is dus geen enkele andere mogelijkheid om dit te doen.

Stel dat je dus een virus binnen haalt, dan kan je dat dus op z'n ergst in user space draaien, want zonder handtekening mag je het dus niet in kernel space laden. Op die manier is het dus zeer zeker een kritiek onderdeel van het security model. Je kan er dan namelijk 100% zeker van zijn dat het OS alleen correcte software draait. En zolang je OS daarmee niet gecompromitteerd is kan je er ook van uit gaan dat het in staat is je user space in de gaten te houden. Virusscanners kunnen op die manier ook effectief alles tegen houden als je een kernel-space driver hebben waarmee ze calls kunnen blokkeren, monitoren of rerouten.

Daarnaast heb je natuurlijk al die andere leuke dingen, zoals updates, en MITM mitigation, maar dat heeft eigelijk geen drol te maken met dit probleem. Je kan namelijk prima zonder Microsoft's toestemming zelf een CA gebruiken. Of zelf een Root CA worden, installeren met de distributie van je eigen software, en daarmee je eigen updates en/of communicatie valideren. Maakt dat het minder belangrijk? Nee, maar het heeft eigelijk dus niks te maken met dit artikel en de waarschuwing van Microsoft.

Als er ook maar 1 private key gelekt wordt heb je een mogelijkheid om een payload te maken die niet door het OS geblokkeerd wordt, en daarmee op een heel eenvoudige wijze een methode om in kernel space in te breken zonder dat ook maar een programma het door heeft. (Met uitzondering van heuristics die meestal niet op een hoog niveau staan en daardoor vaak juist dit soort dingen niet detecteren)

Het onderliggende OS dat toegang tot x86 RING 0 beheert is hier dus van groot belang.

En dat is wat anders dan SSL of MITM. Dit is kernel space toegang!

Wat Apple en Linux betreft:

- Linux distributies gebruiken handtekeningen voor packages uit de officiële package repositories, wat betekent dat de key niet in het bezit van een (mogelijk slordige) developer is. Er zijn dus niet duizenden keys in omloop die afzonderlijk uitgegeven zijn en afzonderlijk ingetrokken moeten worden, maar er wordt gebruik gemaakt van centrale GPG servers.

- Mac OS X en iOS hebben net als Linux een centrale authority die het signen kan blokkeren. Er zijn dus wel per developer keys en certificaten, maar je hebt als developer geen toegang tot je eigen key.

Zowel OS X en iOS als de grote Linux distro's hebben CRL's en OCSP servers voor het achteraf terugtrekken, maar kunnen dus ook van te voren het ondertekenen met een gecompromitteerde key onmogelijk maken. Bij Microsoft kan dit standaard niet.

[Reactie gewijzigd door johnkeates op 16 december 2013 19:27]

Bedankt voor de aanvulling betreft hoe signing werkt. Dat geeft technisch mooi aan wat ik aangaf: Dat zonder key je dus niets kan, maar standaard key verificatie op 'x86' Windows enkel voor drivers/kernel aan staat.

Zet je het wel aan is er echter dus nihil verschil met Linux en Apple. Je latere toevoeging gaat gaat namelijk enkel in op twee zaken.

Allereerste de distributie via de vendor. Ofwel, dat Linux updates en distributies allemaal via een eigen key gesigned worden, is hetzelfde als dat Windows Updates en distributies altijd door Microsoft gesigned worden of op zijn minst via hen gedistributeerd en gecontroleerd. Er zijn dus ook geen "duizenden keys" in omloop van officiele Microsoft en partners distributies die via die officiele kanalen verstrekt worden.

Echter er is niets op Linux dat mij inherent verhindert andere packages buiten die distributie met een andere of zelfs geen key te installeren. Dat is een configuratie instelling die op de meeste distributie sgewoon aan staat. Net zoals er niets is dat mij verhindert om op Microsoft's OS, de signing zo in te stellen dat juist enkel Microsoft een een handje vol partners certificaten geaccepteerd worden.

Het enige verschil is de default en dat is wat ik beschreef. Bij Microsoft staat dat standaard uit omdat gebrukers dat verwachten. Tenzij je Windows Phone of Windows RT neemt, want dan staat het standaard weer aan. Een paar maanden geleden was er nog een artikel waarin ook hier op Tweakers mensen boos waren dat je geen unsigned of alternatief gesignde software op Windows RT kon draaien. Welnu dat is precies het mechanisme waar we het hier over hebben.
Apple heeft het ook standaard op strenge controle staan, omdat het nu eenmaal geen groot ecosysteem buiten Apple zelf heeft. Bij Linux is het dus distributie afhankelijk.

Ofwel, het is niet zozeer OS afhankelijk, maar een configuratie instelling.


Je tweede argument is certificaatbeheer en staat hier los van. Apple is veel strenger en heeft een centraal certifciaatbeheer, wat het inderdaad moeilijker maakt om gecompromeerde keys te misbruiiken. Microsoft hanteert hetzelfde model met Windows Phone.

Nadeel is natuurlijk dat het ecosyteem dan ook volledig via Apple/Microsoft moet lopen. Als je echter wilt, kun je dat model op PC Windows ook instellen. Jij moet dan echter wel elke software van je vendor zelf signen of via Microsoft of speciale partner laten lopen. Bepaalde bedrijven met zeer hoge security wensen doen dat dan ook.


Als je stelling is dat op consumenten PC's de default security instellingen lager staan, ben ik het met je eens. Als je stelt dat het inherent aan het OS is, niet. Het is namelijk een bewuste keuze die gebaseerd is op de wensen van de gebruikers, en wensen van de fabrikant betreft hoe open/gesloten men wil zijn betreft sleutel distributie. Microsoft is hier ironisch genoeg méér open dan Apple en sommige Linux distributies waar je perse contact moet zoeken met de fabrikant om uberhaupt software te mogen distribueren naar het platform. Wellicht is dat slechter, doch in discussies van Android vs Apple, wordt het argument ook regelmatig de andere kant op gemaakt in de zin dat Apple te gesloten' is.

Misschien dat ik niet duidelijk genoeg was;

Je kan op Windows Vista, 2008, 7 en 2008R2 en dan van alle 4 de 64-bits edities zonder handtekening GEEN drivers of andere kernel-space installeren of draaien. Er is ook geen 'setting' om dat uit te zetten.

Ja, je kan je OS in debug modus draaien, maar dat is nou niet echt 'uitzetten' en eerder een 'hack' of iets voor ontwikkelaars.

Op Linux kan je standaard met een desktop package manager ook niet zomaar packages zonder controleerbare handtekening installeren. Dat moet je zelf overriden met root rechten.

Op Mac OS X heb je drie opties:

1. (default): AppStore content en ondertekende content toetstaan
2. Alleen AppStore content toestaan
3. Alle content toestaan

Dat zijn dus echte instellingen. Geen boot-time debug parameters, geen hacks, geen meldingen over 'test modus'.

Maar tot zo ver dus de instellingen van ondertekende software..

Windows x86: alles kan
Windows x64: alleen ondertekend
Linux: alleen ondertekend, als root te overrijden
Mac: instelbaar, standaard alleen ondertekend

Welnu, stel dat je op Windows zit, en je een ondertekend programma hebt dat een ondertekende driver wil gebruiken. Je dubbelklikt, krijgt misschien 1 UAC melding, en that's it. Driver ingeladen. Want hij was ondertekent. Geen vragen, geen meldingen over mogelijke installaties.

Op Linux? Handtekening of niet, je moet altijd root rechten hebben om iets in kernel space te doen.

Op Mac OS X? Handtekening of niet, je moet altijd admin zijn en je wachtwoord invoeren om iets in kernel space te doen.

Dit betekent effectief dat je op Windows als Administrator een ondertekende driver dus niet tegen kan houden. Als jij een programma opstart en dat programma een driver wil installeren, dan gebeurt dat gewoon. Simpel voorbeeld: SLIC Toolkit. Je start het programma, en hop, driver is ingeladen. Geen melding. Geen vraag. Gewoon kernel mode software, ring 0, meteen toegang.

Het wordt door Microsoft dan ook als security feature aangeprezen, die digitale handtekeningen. Sure, leuk voor MITM mitigation en DRM achtige zaken, maar hoofdzakelijk puur en alleen om rouge kernel space software tegen te gaan. Dat is wat Microsoft er van maakt, en dat is dat de praktijk laat zien.

En dat is dan ook waarom Microsoft een waarschuwing geeft, een waarschuwing dat een door henzelf geadverteerde beveiligingsfeature niet goed werkt op het moment dat private keys gestolen wordt. En dat is waar het om gaat. Microsoft maakt een systeem, en developers zijn verantwoordelijk voor de werking. Om dat Microsoft geen beheer heeft over de private keys kunnen ze dus niks tegen gestolen keys doen, behalve afwachten en blokkeren als ze misbruik constateren.

Dat is echter wéér een andere kwestie.

En in dit geval een al sinds Vista besproken kwestie. Die UAC melding die jij even luchtig aanhaalt, is het equivalent van root-rechten. Het is hetzelfde als sudo op Linux. Op Linux kan ik ook zonder waarschuwing, meteen in ring 0 software laden als ik root ben. Op de diverse distributies heb ik dan niet eens signed software nodig!

Ook hier is er nihil verschil tussen Apple, Linux en Microsoft OS. Verschil is enkel dat mensen standaard op Windows OS altijd perse als admin ingelogd willen zijn. Vandaar dat extra UAC window, om nog enige scheiding tussen een gebruiker en local admin aan te brengen. UAC is niet meer of minder dan een sudo commando.

Echter er is een super simpele optie om dit aan te pakken als systeem beheerder: Net als op Linux, gewoon de gebruiker niet als Administrator laten inloggen. Er komt dan geen UAC window, maar een keiharde username/password prompt.

Echter de klaagzangen van gebruikers zullen elke dag weer door het kantoor zingen. Toch ken ik divese bedrijven die dit toch gewoon doen.

Mensen vinden het heel normaal dat op Windows (en Android) je 'alles' mag, terwijl je op iOS, Windows RT, Windows Phone 'niets' mag, en Linux gebruikers vinden het heel normaal dat je 'alles' mag, maar jezelf beheerst en het uit jezelf (!) niet doet.

Ook hier dus is er geen verschil in OS design, maar wederom een verschil in default configuratie ivm verwachtingen van gebruikers. Wie echter wil, kan het net zo dicht timmeren.

Verder haal je wederom die private keys aan, maar zoals uitgelegd gaat dat om het key distributiemodel. Dat is geen OS kwestie, maar een ecosysteem kwestie. Alles in eigen beheer geeft minder punten van aanval, maar gaat ten koste van het open ecosysteem. Apple, officiele Linux distributies en Windows RT/Phone zijn minder open, dan bijvoorbeeld Android en Microsoft Desktop in dit opzicht.

Dat is niet slechter, maar een distributiekeuze. Niets verhindert je om Linux helemaal open te gooien zonder certifiaatcontrole (veel Linux gebruikers installeren buiten de gecertificeerde kanelen om) of als Windows PC systeembeheerder die andere keys allemaal buiten te sluiten. Bij Apple en Windows Phone/RT heb je geen keuze.

Eindelijk iemand die met goede argumenten komt. Ik ben blij dat je je standpunt zo goed weet te verdedigen!

Rest nog dit:

We hebben het hier inderdaad over meerdere elementen:

- sudo-achtige zaken (UAC vs. Sudo vs. Mac OS X prompt)
- distributiemodellen (Alle software vs. Signed software vs. Zelf kiezen)
- default settings (UAC aan/uit/password vs. Linux als Root draaien)

Maar het enige wat ik niet heel sterk terugzie is Microsoft's keuze om het ondertekenen van software zo vrij te maken dat het een aanvalsvector op zich wordt, wat het hele idee van ondertekende software bijna teniet doet. Software ondertekenen werkt zoals met alle trust systemen alleen als iedereen het goed doet. Gezien je er van uit kan gaan dat niet iedereen het goed kan doen, zou ik er altijd voor kiezen om een centrale key/signing authority op te zetten, al dan niet met losse keys per developer. Het maakt voor de eindgebruiker niks uit, want die kan altijd nog kiezen om geen handtekening te vereisen, maar voor sysadmins die graag alleen ondertekende software draaien is het weldegelijk een groot verschil. Je kan er dan namelijk opeens niet meer van uit gaan dat de microsoft-signed software ook daadwerkelijk door de uitgever ondertekend werd.

En dat is waar het een security issue wordt, om dat het toch wel een best practice is om op ondertekende software te vertrouwen, wat in veel gevallen tot blindelings vertrouwen leidt. Zo wordt het geadverteerd, maar zo wordt het dus ook misbruikt. Pas nadat het een security feature werd was het de moeite waard om het aan te vallen.

Dit is wel erg kort door de bocht

Wauw, wat een goed onderbouwde stelling!

Net zoals alle andere OSsen zijn digitale handtekeningen meestal de sleutel tot kernel space toegang, maar bij Microsoft is het mogelijk om een key van een ander te stelen en te gebruiken om je software mee te ondertekenen. Dit is dus een belangrijk component van het beschermen van de kernel space om dat Microsoft altijd de controle heeft over wat er wel of niet mag draaien. Ze kunnen via OCSP of hun CRL namelijk certificaten intrekken. Maar ze kunnen niet private keys beheren of op een andere manier het digitaal ondertekenen beheren. Op z'n best zullen ze dus na dat een key gestolen is, en dit bekend geworden is een certificaat kunnen intrekken.

Niet alleen bij Microsoft. Ook bij anderen. Zodra je de private key hebt, waarmee het request ondertekend is, dan kan je gewoon je gang gaan. De private key moet je dus gewoon van het device verwijderen wanneer dit kan na het importeren/activeren van het certificaat.

Nee, niet ook bij anderen. Microsoft hanteert op de desktop OSsen als enige het model waarbij de developer zelf de private key in handen heeft.

Daarnaast is jouw oplossing geen oplossing. Je hebt je private key nodig voor elke keer als je iets wil coderen/ondertekenen. Dus van je device verwijderen maakt het onmogelijk om verder te werken.

Ik snap dat men het altijd gemakkelijk wil. Maar als ik dus een willekeurig device kan hacken, daar de private key van af kan halen, dan kan ik de certificaten gewoon misbruiken. Een private key waarmee de aanvraag gedaan wordt voor een publiek certificaat moet gewoon gegarandeerd veilig zijn.

Ik durf het zelfs zo te stellen dat een software ontwikkelaar welke software ontwikkeld en deze netjes signed, En waarvan een private key uitlekt gewoon out of business moet gaan, want hierdoor is namelijk aangetoond dat het signen bij dat bedrijf een wassen neus is en dat je deze ontwikkelaar gewoon als onbetrouwbaar moet zien.

Kortom. Gewoon testen met test certificaten en productie builds met een uiteindelijk productie certificaat signen.

En ieder OS bied de mogelijkheid om test root-certificaten of test-intermediate certificaten te "injecteren" zodat een test build getest kan worden met een test certificaat.

Volgens mij snap je het punt niet. Ontwikkelaars gaan echt niet zelf een certificatje en een key'tje op hun eigen fijne PC'tje zetten...

Je hebt gewoon automatische buildstraten die na elke commit opnieuw een build moeten uitbrengen die dan automatisch door de CI test gaat. Dat is voor O, T en A misschien nog met testcertificaten te doen. Maar uiteindelijk komt er toch een automatische P build aan bod, en dan moet je dus die key hebben.

Sure, je kan je key op een smartcard zetten, en hem met een wachtwoord beveiligen, maar dan nog kan ie gestolen worden. Het is niet alsof een complete PC gejat wordt waar 'toevallig' een key op stond. Dit zijn digitale diefstallen, dus die lezen gewoon de key uit het geheugen uit op het moment dat ie gebruikt wordt.

Daarnaast is dit niet een case van het beheren van je keys, want daar zijn we al voorbij. De keys zijn al gestolen, en zijn al misbruikt.

Zelfs als je een bedrijf hebt op CMMI niveau 5 dat ook nog eens ISO27000 maximaal implementeert, dan nog kan een key gestolen worden.

[Reactie gewijzigd door johnkeates op 17 december 2013 18:12]

Dus, je P build draaien op een losse omgeving zonder toegang tot Internet. Sources er naar toe via een geëncrypt systeem, ja, dat kan gewoon via een oplossing zoals USB disk, Tape, USB key of wat dan ook. Build draaien en wat er uit komt via de zelfde technologie er weer af.

Ja, en toch krijg je dan prima een virus of RAT of sneakernet infectie binnen. Je kan nu wel leuk allemaal 'oplossingen' uit je mouw schudden, maar de bedrijven met mensen die meer weten dan jij en er duizenden euro's tegenaan gooien hebben hun best echt wel gedaan.

En wat dacht je van infecties in kerncentrales bij geïsoleerde systemen. Of het ISS?

Het is niet zo eenvoudig als je het nu voor laat komen.

Daarbij komt nog dat een geautomatiseerd systeem toch echt verbinding moet hebben met een centrale repository ergens. En dat de business value van een geïsoleerd systeem echt niet de value van snel kunnen werken overstijgt.

In mijn wereld is de private key heilig en dient zich nooit op een benaderbaar systeem te bevinden. Ok er zijn situaties dat het niet anders kan, bijvoorbeeld wanneer je een certificaat moet implementeren dan moet je op dat moment een risico nemen door de private key tijdelijk weer beschikbaar te hebben. Een noodzakelijk kwaad helaas wat ik ook liever had gezien. Maar wat ook tevens de zwakte aangeeft van het hele Certificaten gebeuren.

Of je zorgt ervoor dat je ontwikkel certificaten niet zomaar in het wild te gebruiken zijn...
Bij apple moet je bv eerst handmatig het certificaat op het device zetten alvorens je kan testen.

Onwerkbaar.
Ik werkte ooit met een Daily Build systeem, waar iedere nacht 50 bestanden werden ondertekend. Eisen dat dat handmatig moet gebeuren is een stap terug in de tijd.

Het daily build systeem maakt builds voor een test-omgeving die dus met test-certificated getekend worden. Na een sprint doe je dan een release build, met het "echte" certificaat.

En als dat niet flexibel genoeg is kun je met twee test-certificaten werken. Eentje voor de gewone ontwikkeling en daily builds, en dan een tweede test certificaat dat als 'test release' werkt. Je kunt zou kijken of bij het verwisselen van het certificaat, inderdaad de gewenste beveiligingen en beperkingen die daar aan hangen werken. Zo kun je dus 'release signing' testen zonder het release certificaat te hoeven gebruiken.

En het echte release certificaat gebeurt dan op een apparte server enkel toegankelijk voor die selecte groep mensen die noodzakelijk is.

Echter natuurlijk valt en staat alles met de opslag van dat release certificaat.

En er komt natuurlijk een kosten-baten analyse aan te pas. Gaat die investering echt iets opleveren? Wij vinden van wel, maar als het ook maar 1 euro goedkoper is om het niet te doen en de schade in te calculeren, dan gaan bedrijven gewoon lekker alles aan elkaar knopen.

Het is maar waar je prioriteiten liggen, als je makkelijk continu nieuwe releases kunnen opleveren belangrijker vind dan security dan heb je gelijk. Je moet je misschien al afvragen of je wel elke nacht een nieuwe release moet willen produceren. Mijn mening is juist dat verminderde security een stap terug in de tijd is. Kijk maar om je heen op dit moment, overal begint duidelijk te worden dat zo'n beetje alles wat maar aan het internet hangt onveilig is en feitelijk om maar 1 simpele reden, namelijk dat mensen gemakzuchtig en gadget geil zijn.

Dit gaat niet om ontwikkelcertificaten, maar om certificaten om aan te tonen dat een applicatie echt door die ontwikkelaar gemaakt is. Het kan ook een soort certificaat zijn wat gebruikt wordt door websites om de verbinding te beveiligen en te bewijzen dat de website echt is wie die zegt dat die is. Als iedereen handmatig hiervoor certificaten zou moeten toevoegen, dan zou dat erg omslachtig zijn EN gaat de veiligheid omlaag omdat je dan iedere keer zelf moet controleren of een certificaat echt is.

Moet je toch eens zien hoe vernuftig die malware makers aan het worden zijn zeg. Techneuten die grote merken een dikke hak zetten tegenwoordig en bij die grote merken werken ook flinke techneuten.

Het wordt serieus tijd voor een heel ander internet waarin encryptie de overhand neemt in alle vormen van communicatie. Daarbij is de structuur van een blockchain zoals van Bitcoin nog wel het beste voorbeeld. Waarbij alles gedecentraliseerd wordt en een hack bij de ene server niks uitmaakt voor de algehele structuur. Waarbij alle informatie gefragmenteerd wordt opgeslagen door middel van verschillende lagen servers. Wil je een certificaat overnemen dan zul je alle servers die een fragmentatie van de certificaat bezitten moeten hacken alleen weet je niet welke dat zijn.

Het kan niet anders dat we die kant op moeten gaan. Want wat er nu aan de gang is is peanuts geworden voor de criminelen.

Een gedecentraliseerd internet bestaat al, dat heet het internet.

Internet is niet gedecentraliseerd. Daar zorgen de root DNS servers inmiddels al voor welke ook nog beheerd worden door een bepaald land. Als daar een wijziging wordt aangebracht dan heeft iedereen er last van door middel van replicatie.

En wees eens eerlijk, je begrijpt mijn punt in voorgaande bericht heus wel toch? Ik weet dat het voor sommige eng zal klinken om gefragmenteerd te informatie vandaan te moeten halen, maar om betreffende problemen als wat in dit nieuwsbericht staat tegen te gaan is mijn voorstel helemaal niet zo offtopic als dat het wordt gemodereerd.

Als je meerdere checkpunten hebt op het internet waarbij je de herkomst kan controleren dan wordt het een stuk moeilijker voor criminelen om er gebruik van te maken. Wordt de ene checkpunt gehacked dan zijn er nog tig die dan zeggen, ho, dat checkpunt heeft een hele andere "handtekening" dan wat wij hebben en dan gaat de handeling niet meer verder vanuit de server die een verkeerde handtekening heeft. Uitermate handig voor phishingmail bijv.

Het kan aan mij liggen uiteraard, maar ik vind het idee nog niet zo gek hoor. En zover komt het echt nog wel, alleen had ik verwacht op Tweakers wat meer bijval te krijgen haha.

Internet is prima gedecentraliseerd. Windows niet. En Mac OS X niet. Maar de rest echt wel hoor.

Waar jij op doelt is de massa. De massa gebruikt allemaal hetzelfde, wat centralisatie in de hand werkt. Het netwerk en de technologie is dus niet zozeer gecentraliseerd, maar alle ISP's en vendors gebruiken dezelfde root servers, dezelfde CA's en beheren centraal hun eigen klanten.

Daarnaast is een hack op een punt in het internet geen probleem voor 'de rest'. Stel dat jij een AS beheert en lekker met het verkeer gaat knoeien, dan gaan andere ASsen echt niet meer hun verkeer via jouw netwerk routeren... genoeg andere routes om uit te kiezen.

Qua encryptie en verificatie is er ook genoeg aanwezig om dit lekker automatisch te laten gebeuren (zoals nu al gebeurt). Dus waar jij het over hebt ligt a) niet bij de techniek en huidige stand van zaken, en b) is alleen centralisatie bij consument die daar zelf voor zorgt.

Offtopic:
Ligt het aan mij of zie ik in vele security artikelen leaseweb reclame

*zet alu-hoedje op*

Misschien hebben ze dat bij Leaseweb nodig..... ze zijn onlangs geheel gecompromitteerd...

Waarom zou je deze certificaten ook bijhouden op een systeem dat via internet bereikbaar is? Ik ga men passwords.txt bestand ook niet op een ftp server zetten die over ter wereld bereikbaar is... Dat zet je op je USB ofzo.

Men zou je al fysiek moeten overvallen en dan nog.