image

Juniper gaat NSA-algoritme uit ScreenOS verwijderen

maandag 11 januari 2016, 12:36 door Redactie, 8 reacties

Netwerkfabrikant Juniper gaat een door de NSA ontworpen encryptiealgoritme uit ScreenOS verwijderen, het besturingssysteem voor firewall-apparaten waar onlangs nog twee backdoors in werden gevonden. Dat heeft het bedrijf afgelopen vrijdag via de eigen website bekendgemaakt.

Het gaat om de Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG) waarmee willekeurige getallen worden gegenereerd. De NSA zou het algoritme opzettelijk hebben verzwakt, zodat de gegenereerde getallen helemaal niet willekeurig zijn en het mogelijk wordt om versleutelde informatie te ontsleutelen. Ook de ANSI X9.31-standaard voor het genereren van willekeurige getallen wordt vervangen. Beide nummergeneratoren worden vervangen door de technologie die Juniper in het Junos-besturingssysteem gebruikt.

Junos is het op FreeBSD-gebaseerde besturingssysteem dat Juniper in de eigen routers gebruikt. De update die hiervoor gaat zorgen zal in de eerste helft van dit jaar beschikbaar worden gemaakt. Onlangs werd bekend dat erin ScreenOS 'ongeautoriseerde code' was toegevoegd. Het ging om twee verschillende backdoors. Een backdoor in de vpn-implementatie waardoor een passieve afluisteraar vpn-verkeer kan ontsleutelen en een tweede backdoor waardoor een aanvaller de authenticatie van ssh en Telnet kan omzeilen en zo beheerderstoegang kan krijgen.

Juniper bracht een update uit om de problemen te verhelpen. Vervolgens besloot het bedrijf zowel de code van ScreenOS als Junos OS te controleren. In beide besturingssystemen werd geen andere ongeautoriseerde code aangetroffen, zo laat het bedrijf weten. Het onderzoek liet verder zien dat het veel lastiger zou zijn om de in ScreenOS gevonden backdoorcode aan Junos OS toe te voegen. Het onderzoek naar de ongeautoriseerde code is echter nog niet afgelopen.

Reacties (8)
11-01-2016, 12:42 door Anoniem
Zie ook:
http://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html
Voor een goede samenvatting van het VPN decryptie issue
11-01-2016, 15:11 door Anoniem
verwijderen, updaten, het is maar hoe je het wilt benamen.
11-01-2016, 15:56 door Overcome
Zo zo, nu al? Het is nog maar een jaar of 10 duidelijk dat er iets heel erg fout zit met dat algoritme.

http://csrc.nist.gov/groups/ST/crypto-review/documents/dualec_in_X982_and_sp800-90.pdf
11-01-2016, 16:09 door Anoniem
Tuurlijk nu al... NSA heeft tijd nodig om iets anders te implementeren in screenos en junos.
11-01-2016, 19:48 door karma4
Had liever een antwoord gezien hoe zoiets er ooit in gekomen is. De twijfel aan de kwaliteit van het ontwikkelproces (release management - controles -testen) blijft zo staan.
11-01-2016, 20:37 door Anoniem
Door karma4: Had liever een antwoord gezien hoe zoiets er ooit in gekomen is. De twijfel aan de kwaliteit van het ontwikkelproces (release management - controles -testen) blijft zo staan.

De keuze voor een RNG met backdoor-mogelijkheid is vanaf design en implementatie gemaakt - helemaal in het begin van een ontwikkelproces dus.
De bedoelde Juniper-eigen code gebruikte alleen een andere startwaarde dan de van de NSA afkomstige uit de NIST standaard - Of de Juniper/Netscreen oorspronkelijke startwaarde ook een backdoor opleverde (en voor wie ) is niet bekend . Het ligt heel erg voor de hand, maar is niet direct bewijsbaar .Er is geen keuzemethodiek voor gegegeven die dit uitsluit.

Het is deze backdoor-bij-design waar een ander slot op gezet is door "anderen".

De patches van de afgelopen paar weken voor dit probleem hebben slechts startware die buiten Juniper om veranderd was weer teruggebracht. Inderdaad zou meer informatie hoe en door wie een ander slot op de door Juniper/Netscreen gekozen backdoor gezet is ook erg interessant zijn.

Datzelfde geldt voor het (door weer een andere partij ?) toegevoegde 'touwtje uit de brievenbus' - het ssh/telnet hardcoded password en hoe dat in de release gekomen is.

(@anoniem 11-jan 12:42 - thx. uitstekende link)
13-01-2016, 10:37 door Anoniem
Vraag me af hoeveel beter hun eigen Random Number Generators zijn. Enige voordeel is dat de NSA niet direct inzicht in het algoritme heeft. RNGs zijn vaak zwakker omdat ze niet kunnen hebben dat de random numbers op zijn als ze iets encrypted willen sturen. Zeker niet als er een 10Gbit link een minuut moet wachten op nummers.
13-01-2016, 19:26 door Anoniem
Door Anoniem: Vraag me af hoeveel beter hun eigen Random Number Generators zijn. Enige voordeel is dat de NSA niet direct inzicht in het algoritme heeft. RNGs zijn vaak zwakker omdat ze niet kunnen hebben dat de random numbers op zijn als ze iets encrypted willen sturen. Zeker niet als er een 10Gbit link een minuut moet wachten op nummers.

Als je een verstandige designer bent heeft de NSA absoluut inzicht in het algorithme - omdat je een goede standaard gebruikt voor je pRNG , en niet zelf gaat zitten klooien .En kunnen ze daar niks mee.

Maar hoe kom je bij al je impliciete beweringen ?
Dat je een zwakke RNG _nodig_ zou hebben omdat je zo reusachtig veel RNG getallen nodig hebt en speciaal bij high speed verbindingen ?

Ken je werkelijk een product waarbij dat een probleem is ? Of verzin je het probleem omdat je zelf bedacht hebt hoe vpn encryptie zou werken - met een waanzinnige high speed behoefte aan (true) random numbers ?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.