FreeBSD-ontwikkelaars: rn-generators in Intel- en VIA-cpu's zijn onbetrouwbaar

De ontwikkelaars van FreeBSD hebben in versie 10.0 van het besturingssysteem aanpassingen doorgevoerd aan de wijze waarop willekeurige getallen worden gegenereerd. De bouwers vertrouwen na de NSA-onthullingen niet langer de random number generators van Intel- en VIA-processors.

Uit de onthullingen van Edward Snowden kwam onder andere naar voren dat de NSA bewust kwetsbaarheden heeft geïntroduceerd in encryptie-algortimen, zoals het Dual_EC_DRBG-algoritme dat mede door de NSA is ontwikkeld. Hierdoor zouden random number generators deels voorspelbare uitkomsten genereren, waardoor het voor de NSA gemakkelijker wordt om de betreffende encryptie te kraken. De NSA zou ook in andere encryptiestandaarden kwetsbaarheden hebben gebouwd, maar welke dit zijn is niet bekend. Ook zou de geheime dienst met tal van hardwarebedrijven hebben samengewerkt.

Ontwikkelaars van het FreeBSD-besturingssysteem vrezen dat de NSA ook heeft samengewerkt met chipfabrikanten, zo meldt ArsTechnica. Hierdoor bestaat er de kans dat er aan de hardwarematig werkende random number generators kwetsbaarheden zijn toegevoegd. De verdenking is onder andere gevallen op Intel- en VIA-processors met respectievelijk RDRAND- en Padlock-generators.

Om de beveiliging op te schroeven hebben de developers in versie 10.0 van FreeBSD de nodige aanpassingen doorgevoerd bij het genereren van willekeurige getallen. Zo zal FreeBSD een willekeurig getal afkomstig van de RDRAND- of Padlock-generator niet langer direct als uitgangspunt nemen. Een eigen softwarematig algoritme met de naam Yarrow zal eerst worden losgelaten op de hardwarematig gegenereerde waarde om te zorgen voor voldoende entropie. Door deze implementatie moet er voldoende zekerheid aan het OS zijn toegevoegd om veilig encryptie te kunnen gebruiken, zo stellen de ontwikkelaars.

Reacties (66)

[Verwijderd]

Wel interessant dat het weer de ontwikkelaars van FreeBSD zijn die hiermee komen. Eerder ook al waren het FreeBSD-developers die aantoonden dat het (in theorie) mogelijk was om een wachtwoordsleutel te 'stelen' op dezelfde machine door optreden van ruis bij HyperThreading. Om die reden werd het gebruik van HyperThreading een potentiëel veiligheidsrisico genoemd, alhoewel het niet heel eenvoudig is hiervan effectief misbruik te maken.

Het idee om toch gebruik te blijven maken van hardwarematige versnelling van random number generators (RNG) maar deze zelf nog wat op te pimpen lijkt mij uitstekend. Verder tonen deze ontwikkelingen aan dat encryptie zeker niet zoals vaak gezegd wordt altijd veilig is. Door een combinatie van technieken is het vaak goed mogelijk in bepaalde situaties encryptie te kraken, ook AES encryptie. Als er één partij is op de wereld die de middelen, mankracht en motivatie heeft om dit ook daadwerkelijk grootschalig aan te pakken, dan is het de Amerikaanse NSA wel.

Kortom, wees verstandig en gebruik waar mogelijk een combinatie van encryptietechnieken. Dat is wellicht de beste bescherming tegen algoritmen die vanbinnenuit gecomprimiteerd zijn.

[H!GHGuY]

Linux deed dit al langer. Bij BSD komen ze dus eigenlijk een beetje achter.

Recent kwam ook deze random number generator naar boven:
http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
Hier willen ze OS-level timing jitter gebruiken om random numbers te genereren. Allerhande CPU events (bvb cache miss latency, TLB miss latency, pipeline stalls door allerhande redenen) en OS-level jitter (wanner in in userspace gedraaid wordt: page faults, context switches, etc).

Zeer interessante ontwikkeling om random numbers te genereren die zeer moeilijke te manipuleren zijn.

[Dim]

Om dit een beetje in perspectief te plaatsen: de FreeBSD developers zijn al een tijdje aan het denken over het verbeteren van de random generator infrastructuur. Het plan is om de huidige Yarrow implementatie te vervangen door zijn verbeterde opvolger, Fortuna. Maar aangezien de FreeBSD 10.0 release al vrij dichtbij kwam, was er niet genoeg tijd om dat volledig te implementeren.

Vandaar dat ze hebben gekozen om een aantal eenvoudigere dingen in de huidige (Yarrow) implementatie te fixen, waaronder dus het beschouwen van hardware RNGs (zoals de Intel Ivy Bridge, maar ook de wat oudere Via Nehemiah) als slechts één van de beschikbare bronnen van entropie, in plaats van de enige. Yarrow "mixt" die bronnen dan bij elkaar en haalt er op cryptografisch verantwoorde wijze random data uit.

En inderdaad, Linux deed dit al eerder: Theodore Ts'o ging tegen de wensen van Intel in om hun hardware RNG als enige bron te beschouwen, en hij was er achteraf kennelijk wel blij om.

[BasieP]

Heel goed dat ze dit doen.

Ik ben zelf windows gebruiker en vind het jammer dat het in windows zo lastig is om dit soort dingen aan te passen. Linux is meer 'plugable' wat dat betreft. Zelfs kernel compilen is mogelijk dus dit kan iedereen (linux of openBSD) gewoon doen als ze het willen.
Ik zou het tof vinden als microsoft en apple dit soort dingen ook gewoon fixen

[Reactie gewijzigd door BasieP op 26 juli 2024 00:04]

[init6]

In een recent artikel op lxer.com werd beschreven dat Linux varianten ook niet backdoor vrij zijn. True, Redhat en Debian zijn open source en iedereen kan de code inzien. Maar hoe veel mensen hebben deze kennis en lezen stuk voor stuk machine taal door om te kijken of er een backdoor in zit en dit ook daadwerkelijk tot op de letter begrijpt?

Daar Redhat een amerikaans bedrijf is kan je al gaan twijfelen of hier wel of niet een backdoor in zit, Debian neemt vervolgens nog eens stukken code van Redhat over waardoor een backdoor van Nix versie naar Nix versie kan gaan.

De NSA heeft Selinux oorspronkelijk ontwikkeld, hoe betrouwbaar is dit systeem dat in vrijwel elke Linux variant tegenwoordig zit.

Open Source wil niet betekenen meer secure of dat er geen backdoor in zit. De recente ontwikkelingen hebben laten zien hoe weinig wij eigenlijk weten wat er gaande is.

[sfranken]

1) Welke code neemt Debian af van Red Hat dan? Zover ik weet, en de laatste keer dat ik keek, geen.

2) Debian/Ubuntu hebben AppArmor, geen SELinux.

[Verwijderd]

True, Redhat en Debian zijn open source en iedereen kan de code inzien. Maar hoe veel mensen hebben deze kennis en lezen stuk voor stuk machine taal door om te kijken of er een backdoor in zit en dit ook daadwerkelijk tot op de letter begrijpt?

Ken Thompson heeft in 1984 al een hack gepresenteerd die nog veel verder gaat dan dat:
http://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html

Je kunt dus een backdoor in een compiler bouwen, die automatisch backdoors in applicaties meecompileert. Als je deze compiler een keer met zichzelf compilet, kun je dus alle sporen van de backdoor wissen uit de source code.
Dus zelfs als je de source code hebt gecontroleerd op backdoors, kun je nooit 100% zeker zijn dat die er niet zijn. Ze kunnen ook in de compiler zelf zitten. En dat idee kun je nog verder doorvoeren: wat als er in de firmware van je PC een backdoor zit, die zichzelf injecteert in de code die je draait? Etc.

[hiostu]

Wat heeft het OS hier precies mee te maken? Het gaat hier om random number generators die in de fysieke hardware aanwezig zijn. Dat ga je software matig niet oplossen aangezien juist software gebruikt maakt van deze random number generators.

[_Pussycat_]

Het OS kan ook zelf 'random' getallen produceren, bv. door tim,ings van interrupts, muisbewegingen, toetsenbordaanslagen, sensoren (voltages, microfoon, etc) te gebruiken. Bij CPUs zonder HW-random-functie moet dit ook.

Intel heeft geprobeerd bij Linux de /dev/random compleet van de intel-generator afhankelijk te maken. Echter lukte dit niet, de Intel-getallen zijn bij Linux maar één van de toevalsbronnen. Zelf als de Intel-generator slecht is maakt dit dus niet uit; een extra bron is altijd beter. Zodoende is er in Linux geen probleem (tenminste als niet GCC besmet is of er andere bugs zijn etc.etc.). Als FreeBSD puur op de Intel-generator vertrouwd, is dit gevaarlijk.

Verder heb je nog andere pseudorandom sources voor bijvoorbeeld numerieke simulaties, welke altijd dezelfde stroom aan getallen uitgeven of die in ieder geval gedeeltelijk voorspelbaar zijn. Deze zijn in OSen ook voorhanden (/dev/urandom in Linux) voor simulaties, spelletjes etc. waar het niet op 'echt' toeval aankomt.

[Reactie gewijzigd door _Pussycat_ op 26 juli 2024 00:04]

[Gropah]

Op het feit na dat de random generator van Intel op een hoog niveau pas werd betrokken bij het genereren van random getallen, waardoor de "macht" van deze random generator redelijk groot is.

[BasieP]

Je OS gebruikt welliswaar de hardware, maar kan d.m.v. software nog een extra random toevoegen om een 'veiligere' seed te krijgen.
Dit is precies wat de OpenBSD bouwers gedaan hebben waardoor ze zelfs onveilige hardwarematige number generators kunnen gebruiken om veilige seeds te krijgen.

[RJG-223]

Ik zou het tof vinden als microsoft en apple dit soort dingen ook gewoon fixen

Als je de de RNG in de chip van intel niet vertouwt, dan heeft het natuurlijk weinig zin wel een amerikaans besturingssysteem te vertrouwen dat je niet alleen niet zelf geschreven hebt, maar waarvan jij (en meer dan 99.99999(9?)% van mensen) zelf niet de sources hebt of kan inzien, én waarvan zelfs de mensen die wel de sources in hebben kunnen zien niet onafhankelijk kunnen verifiëren, dat de versie die gedistribueerd wordt overeenkomt met die sources.

Ik heb het dan natuurlijk nog niet over het vertrouwen in de compiler zelf, en ook niet in het vertrouwen in het OS waarop de compiler draait bij het compileren van het besturingssysteem...

etc. etc.......

[BasieP]

Iedereen met beetje math kennis kan random nummers controleren. Of het nou open of closed source is. Als je random nummer generator goed is en je software OP het systeem die generator gebruikt, weet je in ieder geval dat de random nummer generator niet voorspel baar is, waardoor je perfecte software hackbaar is omdat het systeem geen goede random nummers kan genereren.

Dus, OS moet goede random nummers opleveren, zodat de software op het OS vertrouwd kan worden.
Een stuk software dat encryptie toepast (lees bijv. een webserver met IIS die https dingen doet) genereert random nummers voor die encryptie. Dan kun je wel een perfecte encryptie pakken, maar als hij voorspelbaar is omdat je generator altijd alleen '1' uitpoept dan heb je er niets aan.

[RJG-223]

Iedereen met beetje math kennis kan random nummers controleren.

Dan is nu juist het probleem. Dat kan niet.

Als ik bijvoorbeeld de rij getallen 1, 2, 3, etc. elk met een goed encryptiemechanisme versleutel, dan ziet de versleutelde rij er uit als random getallen. Ze zijn dat niet, maar alleen voor iemand die de encryptiesleutel kent zijn de 'random' getallen volstrekt voorspelbaar. Voor anderen zien ze er volstrekt random uit. Ook voor de wiskundigen onder ons.

Of het nou open of closed source is. Als je random nummer generator goed is

Hoe weet je of die goed is:
als de source niet beschikbaar is om dat te controleren ?
En als je die source niet zelf gecompileerd hebt ?
Met een compiler waarvan je ook weet dat die goed is ?
Op een systeem waarvan je weet dat het goed is ?
(Dat je dus ook vooraf zelf gecompileerd hebt...)
etc. etc.

Dat geldt dus voor closed én voor open source. Waar het bij closed source bij stap meestal 1 misgaat (je hebt geen source), gaat bij open source meestal om stap 2 (binaire distributie) of anders stap 3 (compiler niet zelf ge-audit en gecompileerd).

Maar goed, het gaat dus niet om open of closed source, maar om vertrouwen. Mijn punt is dat als je de generator op de chip van intel niet vertrouwt, dan moet je ook de software van microsoft niet vertrouwen. En ook niet alle andere (open of closed source !) software die je niet zelf heel zorgvuldig ge-audit en gecompileerd hebt. En in feite moet je de software dan ook zelf geschreven hebben, en dus natuurlijk tevens een absolute expert op encryptie-gebied zijn, anders maak je daarbij beslist elementaire fouten.

[Reactie gewijzigd door RJG-223 op 26 juli 2024 00:04]

[Deegeeooh]

Maar goed, het gaat dus niet om open of closed source, maar om vertrouwen. Mijn punt is dat als je de generator op de chip van intel niet vertrouwt, dan moet je ook de software van microsoft niet vertrouwen.

Precies. En zeker niet in het kader van deze discussie als de maker van betreffende OS/platforn (MS/Apple/Google) eveneens partner is van dezelfde dienst die bewust systemen corrumpeert om zich via backdoors toegang te verschaffen.

[BasieP]

Volgens mij begrijp je mijn post niet.
Jij hebt het over encryptie. Ik niet. Ik heb het over random nummers. En ja die worden welliswaar gebruikt voor encryptie, maar je hebt geen sourcecode nodig om een reeks getallen te controleren.

5 seconden googlen levert me al deze hit op:
http://www.johndcook.com/Beautiful_Testing_ch10.pdf

Maar goed, het gaat dus niet om open of closed source, maar om vertrouwen. Mijn punt is dat als je de generator op de chip van intel niet vertrouwt, dan moet je ook de software van microsoft niet vertrouwen.

Dat doe ik ook niet! en ik vertrouw open BSD ook niet, maar als ze elkaar niet vertrouwen, en dus hun eigen wiskunde over die van de ander heen leggen kun je ze wel vertrouwen.

Dubbel blind heet dat.
Typish voorbeeld van balletje balletje waarbij eerst ik de bakjes shuffle (zonder dat jij kijkt), en dan jij (zonder dat ik kijk). Daarna weten we beide zeker dat we het beide niet weten.

[Reactie gewijzigd door BasieP op 26 juli 2024 00:04]

[Goderic]

Iedereen met beetje math kennis kan random nummers controleren.

Nee.
Dat is net heel moeilijk, kijk maar naar het geval met die random generator die de NSA als backdoor had gezet.
Die lijkt heel random, behalve als je de factorisatie kent (kan het fout hebben, heb het artikel niet nagelezen, iig iets moeilijk om zomaar te berekenen) van een bepaald getal dat gebruikt wordt in de functie. Dan kun je net heel veel voorspellen en is de random generator niet meer veilig.

[Oldeberkoop]

Ehm, om verwarring te voorkomen...

Linux ≠ FreeBSD

Allebeide zijn Unix-achtigen, maar het zijn absoluut niet dezelfde operatingsystemen.

Verder leesmateriaal:

http://nl.wikipedia.org/wiki/FreeBSD
en
http://nl.wikipedia.org/wiki/Linux

[BasieP]

Ja je hebt gelijk (aangepast)

[johnkeates]

Je kan XNU zelf compileren als je wil, dus voor Mac OS X kernel-niveau modificaties maken is niet een ramp. Je hebt natuurlijk wel het probleem dat de meeste userland binaries geen sources hebben waar we bij kunnen, dus dat is dan weer niet zelf aan te passen. Gelukkig maken die alsnog gewoon gebruik van wat de kernel beschikbaar stelt, dus zit je alsnog goed.

[foekie01]

edit: excuus, ik heb je reactie verkeerd begrepen.

[Reactie gewijzigd door foekie01 op 26 juli 2024 00:04]

[BasieP]

Ik bedoel niet dat ik hoop dat we onze eigen windows kernel gaan compilen, maar dat microsoft en apple (en anderen) meer tijd/geld steken in zorgen dat hun OS een secure OS is.
Dus dingen als een betere (non-hardware) entropie op random nummers kunnen zij ook gewoon doen.

Ik heb wel eens gelezen dat BSD het veiligste systeem is juist door die near-perfect random nummer generator.

owja en natuurlijk deze:
http://web.archive.org/we.../dilbert2001182781025.gif

[Reactie gewijzigd door BasieP op 26 juli 2024 00:04]

[foekie01]

Ah, ik heb je reactie dus verkeerd begrepen. Excuses. Aangepast.

Ik ben het volledig met je eens overigens. De component based aanpak is gewoon ideaal.

Zou apple overigens niet hetzelfde kunnen doen?
Experts? Iemand?

[Reactie gewijzigd door foekie01 op 26 juli 2024 00:04]

[Raventhorn]

Zou apple overigens niet hetzelfde kunnen doen?

Heb er geen verstand van (ooit een hackintosh gebouwd maar dat was ten tijde van 10.6), maar volgens mij doen ze dat al
De Darwin kernel is in ieder geval op BSD gebaseerd, en volgens mij kan je met kexts (Kernel EXTentions) de functionaliteit van de kernel uitbreiden. (waaronder drivers e.d.)

Het vervangen van zo'n kext lijkt me voldoende om de beveiliging op te schroeven.

[bomberboy]

Het is een beetje off-topic, maar de kernel van MacOSX is gebaseerd op XNU (http://en.wikipedia.org/wiki/XNU) die dan weer gebaseerd is op Mach (http://en.wikipedia.org/wiki/Mach_%28kernel%29 ). En het userland (Darwin) is dan wel gebaseerd op BSD (en vooral FreeBSD 5 sinds 2003, http://en.wikipedia.org/wiki/Darwin_%28operating_system%29)

En ook in windows kan je gewoon drivers installeren die net als in Linux of andere OS'en dergelijke dingen gaan doen.

[sfranken]

Apple doet al hetzelfde. De kernel "Darwin" (eigelijk meer de basis laag) is gebaseerd op BSD 4 en heeft dus het modulaire van BSD. Alle andere dingen zijn modules (genaamd "services") die je zelfs via de CLI/Single User nog kan benaderen/aanpassen.

[servies]

Een 'service' is totaal wat anders dan wat je onder linux een kernel 'module' zou noemen... Die hebben vrijwel niets met elkaar te maken...

[sfranken]

Zo bedoelde ik het ook niet. Alles wat je onder linux een "service" zou noemen is onder Mach (Apple OS dus) ook een service. De kernelmodules zijn kexts.

Laat reageren is nooit goed.

[PPie]

Zou apple overigens niet hetzelfde kunnen doen?

Apple gebruikt al de Yarrow PRNG voor Mac OS X en iOS.
Zie http://en.wikipedia.org/wiki/Yarrow_algorithm

[hiostu]

Microsoft investeert hevig in de veiligheid van het OS. Ze hebben dan ook in de periode tussen XP en Vista het Microsoft SDL framework geintroduceerd.

http://www.microsoft.com/security/sdl/default.aspx

[stereohead]

En hoe gaat SDL de randomness van de rng verbeteren?

Sorry, maar een "Security Development Lifecycle" klinkt meer als iets voor managers. Verkooppraat. Bah.

[hiostu]

Als je niet even de moeite neemt om het te lezen om te kijken wat het precies inhoud dan kan ik het ook niet helpen. Microsoft SDL is een process waarbij security onderdeel is van je software lifecycle. Hier zit dus ook bijvoorbeeld het integraal modelleren van je attack surface om te bepalen waar bv in je API je kwetsbaarheden zitten.

[BèR]

Vat dit a.u.b. niet persoonlijk op, maar wat je nu zegt klinkt dus precies als verkooppraat voor managers, 'integraal modelleren' in plaats van 'rekenfout gefixt in random number generator'.

[bwerg]

"foutje fixen" klinkt mij anders meer in de oren als een scholier die zijn opdracht verkeerd heeft gemaakt. Een goede manier om "foutjes" te zoeken in zulke cruciale systemen is bijv. d.m.v. model-checken, statistische analyse, formele bewijzen. Dit zijn geen typo's die je met een extra keer doorlezen meteen ziet. Zeker bij het testen van bijvoorbeeld protocollen is model-checken eigenlijk heel normaal en totaal geen manager-praat.

Waarmee ik niet zeg dat ik nu ineens het volste vertrouwen heb in Microsoft, maar een serieuze teststrategie is daarvoor wel een voorwaarde, en "foutjes fixen" is geen teststrategie.

[Reactie gewijzigd door bwerg op 26 juli 2024 00:04]

[BèR]

Sorry, ik heb mezelf wat ongelukkig uitgedrukt. Wat ik bedoel is: een bug of codefout daadwerkelijk vinden/oplossen (en dat natuurlijk gestructureerd aanpakken, formeel bewijzen, documenteren, eventuele regressies in de gaten houden) lost in dit geval veel meer op dan allerlei modellen en lifecycle management erop loslaten.

[sanderv]

Lifecycle management is de enige manier om te garanderen en te controleren dat er structureel tijd besteed wordt aan het zoeken, vinden en oplossen van dergelijke problemen, bij voorkeur door er al vroeg in het ontwerpproces en op alle lagen van de softwarearchitectuur aandacht aan te besteden. Bewustwording speelt daar een grote rol in.

BèR, ik ken je verder niet, ben dus niet bekend met jouw ervaring in softwareontwikkeling, en ik onderschat je dus waarschijnlijk, maar je maakt bij mij de indruk alsof je nooit in een serieuze ontwikkelomgeving gewerkt hebt. Ik werk in een middelgrote IT-omgeving met van zo'n 800 man (en vrouw) en wij hebben wel degelijk programma's en processen nodig om te zorgen dat er aan alles gedacht wordt. En zonder managers gaat hier ook niet veel goed. Hoewel wij natuurlijk ook de grapjes maken over hoe nutteloos die rol zou zijn.

[BèR]

Sander, je hebt een prima punt. Bij grote projecten en in grotere omgevingen moet je zeker op management-niveau regie houden, via lifecycle management of hoe dan ook. Anders ontspoort het geheel. Dat ben ik helemaal met je eens. Ook op mijn werk plannen en beheren we de softwareprojecten met een visie vooraf, waar we wel iets flexibeler zijn vanwege de kleinere omvang.
Het beginpunt van deze discussie was echter hoe men de randomness van de software random-number-generator kan verbeteren zodat er veiligere cryptografische sleutels gemaakt kunnen worden.
Ik denk dat daar meer programmeer-inhoudelijke kennis bij nodig is dan management, omdat het gaat om één kleine sub-issue binnen een heel groot pakket. Iemand haalde daar integraal modelleren en lifecycle management bij, en mijn bedoeling was om aan te geven dat dat een abstractieniveau te hoog was
Je besluit in je lifecycle management wat je nog gaat fixen, wat prioriteit heeft etc.. Nadat er dan eventueel gekozen is voor het fixen van dit probleem gaat de programmeur aan de slag, en die programmeur denkt zelf niet na over de eerder genomen management-beslissing.

[Reactie gewijzigd door BèR op 26 juli 2024 00:04]

[hiostu]

Sorry, maar als je al niet eens bekend bent met software lifecycle management...

En ik reageerde op de stelling dat Microsoft en Apple meer moeten doen aan de veiligheid van hun OS dan specifiek op het probleem van een random number generator.

[fevenhuis]

Ik denkt dat aan de hand van het recenste voorbeeld, dat voor Windows XP men dit jaar alvast heeft besloten toch niet een kritiek lek te dichten, het wel duidelijk is hoe dat zit met het "integraal modelleren" van Microsoft.

[sanderv]

Wat is je punt nu, dat een OS van 12 jaar geleden, dat al twee generaties na zich heeft zien verschijnen, niet meer ondersteund wordt vind je een slechte zaak? Of vind je het een slechte zaak dat SDL, met versie 1 in 2004, geen probleem heeft weten te ondervangen in een systeem dat in 2001 uitkwam? Geen enkel proces gaat alle problemen ondervangen, zeker niet met de complexiteit waar Microsoft mee te maken heeft (of andere IT-grootgrutters, Apple, Google). En geen enkele ontwikkelclub gaat alle problemen oplossen: kosten/baten, etc.

[fevenhuis]

Mijn punt is dat Microsoft extended support heeft geboden tot April 2014 en dan maar even besluit dat een zeer kritiek lek niet meteen egdicht hoeft te worden omdat het "toch maar een oud OS is" (of wellicht omdat ze net een nieuw OS uit hebben?).

Het moge bekend zijn dat Microsoft wel vaken gaten en bugs jarenlang laat liggen, omdat het hun beter uit komt, vooral om een nieuwe versie te verkopen.

[Verwijderd]

Wat is je punt nu, dat een OS van 12 jaar geleden, dat al twee generaties na zich heeft zien verschijnen, niet meer ondersteund wordt vind je een slechte zaak?

Twee generaties?
Na XP hebben we al Vista, 7, 8 en 8.1 gehad. Het is maar hoe je telt.

[sanderv]

Nou, kijk eens aan, dat versterkt mijn punt alleen maar Hoe komt het toch dat ik niet aan Vista gedacht had

[Verwijderd]

....
Hier zit dus ook bijvoorbeeld het integraal modelleren van je attack surface om te bepalen waar bv in je API je kwetsbaarheden zitten.

Kwetsbaarheden in de API ???

[BillyTheClit]

Ik begrijp je verzuchtingen, maar tegelijk lijkt het me een utopie om te geloven dat MS, Google en co hier binnen afzienbare tijd iets aan zullen doen.
Volgens deze afbeelding is Microsoft al sinds 2007 (en Google in 2009) toegetreden tot "the darkside" en lijkt het me vreemd dat ze iets zouden ondernemen dat de NSA stokken in de wielen zou steken.
Elk initiatief dat er op dit moment vertoond wordt - door ondermeer Microsoft - is een kwestie van de schijn te redden en het imago bij de klanten wat op te poetsen.
Zolang dergelijke firma's onder (de huidige) Amerikaanse wetgeving vallen zie ik voor hen geen echte mogelijkheid om vragen van de NSA af te blokken in het voordeel van de privacy van hun klanten.

[Zezura]

wordt tijd dat microsoft en apple dit ook gaan doen, willen ze een beetje geloofwaardig blijven.
want wat heb je aan servers encrypte als ze zo te kraken zijn.

[goarilla]

Lopen we niet te hard van stapel hier. FreeBSD doet dit uit voorzorg, omdat ze
het fijne er niet van weten. Apple put voortdurend uit FreeBSD dus als ze dit willen kunnen ze dit overnemen.

We willen super performance dus de operating systemen proberen gebruik te maken van iedere hardware feature ( dus de rng van de cpu ). En nu klagen we omdat de andere besturingsystemen niet even snel reageren als de rapste op een mogelijke cryptografische zwakheid.

[arjankoole]

Apple put voortdurend uit FreeBSD dus als ze dit willen kunnen ze dit overnemen.

Niet helemaal, het userland is voor een heel leuk deel gebaseerd op FreeBSD, maar de kernel is een Mach64 micro-kernel. Op userland niveau zijn ze enigsinds compatible met elkaar, maar op kernel gebied totaal niet.

[Verwijderd]

Volgens mij hebben dat soort bedrijven juist afspraken met de NSA. Intel met MS en Apple en Google vast ook wel. Puur voor marketing natuurlijk doen alsof ze er tegen zijn

[RoestVrijStaal]

Waarom is AMD buiten schot?

Ik kan me niet voorstellen dat AMD's HQ in Sunnyvale (Californië) geen instructies heeft gekregen van de NSA.

[Rawit]

AMD chips hebben geen RdRand / Bull Mountain instructies. Volgens mij ARM ook niet. RdRand is beschikbaar vanaf Ivy Bridge.
En eerlijk gezegd lijkt het me niet dat het is opdragen door de NSA, maar heeft Intel gewoon keurig netjes de NIST standaard geimplementeerd, inclusief de NSA backdoor.
Volgens mij is het idee geweest om het algoritme de standaard te maken in de hoop dat iedereen deze overneemt. Kenbaar maken dat er een backdoor in zit en aandringen op de implementatie bij fabrikanten had de kans op lekken vele malen groter gemaakt.

[Deem]

Hoeveel procent van de servers bevat een AMD processor? Juist, dat is maar een fractie ten opzichte van Intel.

[RoestVrijStaal]

Bron?

Haha Ongeveer hetzelfde principe van valse gevoel van veiligheid dat er zo weinig malware voor MacOSX (pre-intel-cpu-tijdperk) en Linux is omdat het maar een fractie is ten opzichte van Windows op desktops en dus 'onaantrekkelijk' is voor malwareschrijvers.

[Deem]

http://www.itcandor.com/w.../amd-server-q411-fig2.png

En dat verschil is alleen maar groter geworden de laatste jaren.

[Jimmy89]

Had hier toevallig voor het laatst nog over gelezen op het blog van The Invisible Things Lab:

http://theinvisiblethings...ls-upcoming-software.html

In dit blog wordt onderbouwd hoe een backdoor in de random number generator van processoren (zowel Intel en AMD) kan worden getest en is de conclusie dat we ervanuit kunnen gaan dat dit niet het geval is.

Ik vind het prima dat deze techniek wordt gewantrouwd, aangezien er juist meer innovatie en alternatieven uit volgen. Als je kijkt naar de economische kant, dan verwacht ik niet dat Intel hun RNG zal aanpassen. Kijk maar naar de schade die ze met de Pentium (FDIV) bug hebben geleden. Niet te beginnen over de schade die ze aan hun "eigen" (Amerikaanse) volk zouden aandoen indien zulke kwetsbaarheden openbaar worden.

[mg794613]

Wat ik me afvraag hierbij is dat RNG's niet alleen gebruikt worden bij encryptie :

Algoritmische waarschijnlijkheid, Financieel onderzoek, Chaostheorie, Patroonherkenning, Kansrekening, Quantummechanica en Statistiek e.d.

Zijn de onderzoeken die op deze vlakgebieden zijn gedaan ook beinvloed nu? En zo ja in welke mate?

[Verwijderd]

Is dit niet meer hardwarematig probleem ipv software?

[_Pussycat_]

Ja, maar de software hoeft niet op deze RNG te vertrouwen. Linux doet dat bv. niet.

[sfranken]

Heb je van dat laatste een bronvermelding toevallig? Ik kan er niks over vinden.

[MSalters]

Zie Linus' reactie op het idee om de Intel HW RNG uit Linux te verwijderen.

[DeRooienKomen]

Het aanpassen van de software maakt binnenkort helemaal niets meer uit, het is de hardware:
http://arstechnica.com/se...o-intels-ivy-bridge-cpus/

De Thought Police is coming!

“It was terribly dangerous to let your thoughts wander when you were in any public place(internet) or within range of a telescreen(, a mobile phone or a webcam). The smallest thing (a tiny twitch in a mouse-gesture) could give you away. A nervous tic, an unconscious of anxiety, a habit of muttering to yourself__anything that carried the suggestion of abnormality, of having something to hide. In any case, to wear an improper expression on your face(book) (to look incredulous when a victory was announced, for example) was itself a punishable offense. There was even a word for it in Newspeak: Facecrime, it was called.”

- George Orwell, 1984 -

Unlike in [the] present(1983) United States there will be no place for dissent in future Marxist-Leninist America.(hedendaags Federalism public corporation democracy(=51%mob-rule) )

- Yuri Bezmenov -

[Reactie gewijzigd door DeRooienKomen op 26 juli 2024 00:04]

[sfranken]

Artikel beter lezen is ook geen slecht iets. De FreeBSD ontwikkelaars weten dat de hardware mogelijk onbetrouwbaar is en nemen de output van de hardware dus niet meer voor lief maar halen er hun eigen encryptie nogmaals overheen.

[Kridri]

Was dit niet al in Linux? Ik dacht dat ik hier ooit iets over gelezen.

edit,
https://www.linux.com/learn/docs/man/3869-random4

[Reactie gewijzigd door Kridri op 26 juli 2024 00:04]