ARM neemt ssl-ontwikkelaar PolarSSL over

PolarSSL, een bedrijf dat onder dezelfde naam zowel een gratis opensource als een commerciële ssl-bibliotheek in de aanbieding heeft, meldt dat het is overgenomen door chipontwerper ARM. Het is nog onduidelijk wat de plannen van ARM met PolarSSL zijn.

Een overnamebedrag is niet openbaar gemaakt. Ook de toekomstplannen zijn door ARM nog niet ontvouwen, maar PolarSSL geeft aan dat het door de overname goede kansen ziet om op de markt voor embedded devices terrein te winnen. Verder geeft PolarSSL aan dat het bestaande klanten blijft bedienen.

De ssl-bibliotheek van PolarSSL is in 2008 ontstaan als fork uit de code van het XySSL-project. Projectleider achter PolarSSL is de Nederlander Paul Bakker; hij zal bij ARM PolarSSL blijven aansturen.

In tegenstelling tot het breed gebruikte OpenSSL is de code van PolarSSL compacter: de library vereist slechts 64KB werkgeheugen. Daarmee is de ssl-bibliotheek onder andere interessant om gebruikt te worden in embedded-apparaten. PolarSSL draait bovendien op een groot aantal platformen en besturingssystemen. De Nederlandse overheid koos PolarSSL als onderdeel voor zijn opensource OpenVPN-NL-project.

Inmiddels biedt PolarSSL zijn code naast de basis die opensource is ook op commerciële basis aan, waardoor bedrijven aanpassingen in de code kunnen doorvoeren zonder dat deze volgens de GPL-licenties gepubliceerd moeten worden. Ten opzichte van OpenSSL claimen de makers dat zij betere documentatie leveren, evenals meer ondersteuning.

Reacties (27)

[gertvdijk]

PolarSSL is inderdaad een mooi alternatief voor OpenSSL en kent overigens ook een Nederlandse oorsprong in de persoon van Paul Bakker. Als je begint met ontwikkelen en je ziet code van/met OpenSSL versus die met PolarSSL dan zal je begrijpen waarom er naast de securityaspecten nog wel eens wat anti-OpenSSL wordt betoogd.

Dankzij OpenVPN-NL heeft ook de reguliere OpenVPN sinds versie 2.3 ook ondersteuning voor andere SSL implementaties dan OpenSSL. Momenteel wordt voornamelijk ontwikkeld voor de OpenVPN-PolarSSL variant, die feitelijk een push is naar upstream vanuit OpenVPN-NL. In de tijd van Heartbleed bleek de noodzaak voor alternatieve cryptoimplementaties ineens heel belangrijk.

Je vindt PolarSSL trouwens ook terug in PowerDNS, voor de cryptografie die komt kijken bij DNSSEC. En ook PowerDNS van Nederlands komaf, trouwens.

Hoewel PolarSSL een (bijna) volwaardig alternatief is, blijft de minder vrije GPL-licentie de reden waarom OpenSSL (BSD) nog zo populair is. De BSD-licentie is net even wat meer permissive en dus aantrekkelijker voor gebruik in commerciële producten. De dual-licensing van PolarSSL maakt het dan wel goed mogelijk, maar het blijft een drempel.

[Reactie gewijzigd door gertvdijk op 27 juli 2024 09:24]

[Eloy]

Hoewel PolarSSL een (bijna) volwaardig alternatief is, blijft de minder vrije GPL-licentie de reden waarom OpenSSL (BSD) nog zo populair is. De BSD-licentie is net even wat meer permissive en dus aantrekkelijker voor gebruik in commerciële producten. De dual-licensing van PolarSSL maakt het dan wel goed mogelijk, maar het blijft een drempel.

Ik denk ook dat de mensen van OpenBSD een zeer goed punt hebben als ze zeggen dat ze liever zien dat hun code (van zeer hoge kwaliteit) op zoveel mogelijk plekken wordt gebruikt dan dat ze zien dat mensen hun eigen crappy crypto lib gaan ontwikkelen voor closed source software.

Neemt niet weg dat ik GPL nog steeds beter vind voor veel andere typen software waar het niet zo erg als er hier en daar een bugje in zit. Het maakt de ontwikkeling van software gewoon veel sneller tov BSD waar het vaak wordt geforkt richting closed source

[Reactie gewijzigd door Eloy op 27 juli 2024 09:24]

[OddesE]

Ben ik niet met je eens. BSD style licenses geven de vrijheid om het op te nemen in closed source. Ja. Maar tenminste kan elke wijziging zo toegevoegd worden. Geen rompslomp.

GPL daarentegen leent zich goed voor dual-licensing constructies. Daar wordt die dan ook veel voor gebruikt. Maar een groot nadeel is dat die dual licensing software minder makkelijk gewijzigd kan worden. Stel dat je nu een feature toevoegt aan PolarSSL, dan gaat het bedrijf achter PolarSSL vragen of je een verklaring wilt tekenen dat je hun een (kopie van) het copyright geeft; die is namelijk nodig omdat ze anders de code niet kunnen toevoegen aan hun commerciële versie....

Ironisch genoeg kan de ontwikkelaar van een GPL licensed software pakket, als die software dual licensed is, niet zomaar een wijziging van een derde opnemen in zijn distributie. De reden hiervoor is dat die wijziging een derived work is en daarmee automatisch onder de GPL valt. Zou deze worden toegevoegd aan de versie met de commerciële licentie, dan zou de 'quid quo pro' clausule in de GPL in werking treden die eist dat de source van afgeleide software ook onder de GPL valt. Nu valt de commerciële versie ook ineens onder de GPL en is dus gratis. En dat is niet de bedoeling.

Overigens trekt de GPL de original publisher van de software ook voor. Die is namelijk de enige die de software kan dual licensen. Alle andere auteurs kunnen dat niet (niet me het origineel en ook niet met hun aanpassingen). Verder kunnen andere auteurs hun wijzigingen alleen in de distributie krijgen als ze een waiver ondertekenen dat ze het copyright ook overdragen omdat anders het dual licensing model in gevaar komt. Al met al nogal vreemd vind ik.

[lvmeijer]

Het moge duidelijk zijn dat Internet of Things de komende jaren erg groot gaat worden. Probleem met low-cost en energiezuinige microcontrollers is dat ze niet krachtig genoeg zijn voor TLS. Cryptografie en certificaatvalidatie zijn relatief zware taken. De komende jaren zullen we zien dat meer IoT devices een HTTPS endpoint gaan krijgen (of andersom, dat ze verbinding maken met een HTTPS endpoint, bijvoorbeeld in de cloud). Verbaast me daarom niets dat ARM SSL/TLS kennis in huis wil halen.

[Reactie gewijzigd door lvmeijer op 27 juli 2024 09:24]

[analog_]

Het voornaamste wat duur is, is asymmetrische cryptografie, echter met een AES-CCM/GCM (perfect forward secrecy, wat overigens een van de CPU zwaardere methodes is) kan je een symmetrische key pre-seeden (eenmalige init phase) welke voor ~35 TB dataverkeer veilig wordt geacht, je kan dus prima rond de beperkingen werken aangezien ik er prat op ga dat zon BLE chip meer dan dat ooit in zijn leven zal rondkwekken.

[Anonymoussaurus]

Ik ben nu wel benieuwd wat WEL de plannen zullen zijn. Wat nou een chipmaker met een SSL ontwikkelaar moet, ik weet het niet. Is dus nog niet bekend, maar afwachten dan.

[Reactie gewijzigd door Anonymoussaurus op 27 juli 2024 09:24]

[DeBierVampier]

In tegenstelling tot het breed gebruikte OpenSLL is de code van PolarSSL compacter: de library vereist slechts 64KB werkgeheugen. Daarmee is de ssl-bibliotheek onder andere interessant om gebruikt te worden in embedded-apparaten.

[i-chat]

ja maar arm is geen apperatuur maker maar een cpu maker/ontwerper. dus tenzei ze van plan zijn een chipset met hardware matige ondersteuning voor ssl verbindingen te maken, hoort dit eerder thuis in de OS laag en niet in de hardware laag..

[Armin]

hoort dit eerder thuis in de OS laag en niet in de hardware laag..

De grenzen tussen hardware en software zijn tegenwoordig heel vaag. Harwdare is vaak deels programeerbaar en software zit vaak standaard ingebakken in chips. Denk aan AMD APU's die een ARM controller met firmware hebben om Trusted Computing mogelijk te maken. Of in telefoons radio chips waar de firmware dynamisch geladen wordt bij elke start.

ARM kan zo een kant en klaar design aanleveren. Klanten immers zullen vaak opkijken tegen software kosten die nodig zijn om een "secure element" te maken, naar vooral te onderhouden. Of die firmware dan in de OS laag zit of dat het zoals bij veel drivers een kant-en-klare bin is die enkel bij boot in de chip 'geschoten' moet worden is dan afhankelijk van het systeem waar in het gebruikt wordt.

[MSalters]

64 kB is prima op een ARM chip te integreren. Dat zou betekenen dat je de SSL en/decoding op een coprocessor kunt doen zonder main memory te belasten.

[OddesE]

De SSL library zelf neemt maar 64 KB in beslag... Maar datzelfde geldt niet voor de payload. De data die versleuteld wordt zal nog steeds van en naar main memory geschreven moeten worden.

[johnkeates]

ARM heeft ook bibliotheken he... ze leveren niet alleen ontwerpen maar ook implementaties. Sommige fabrikanten gaan voor alles, dan hoeven ze zelf minder te doen, maar andere fabrikanten maken juist weer zo veel mogelijk zelf (bijv. Apple, die gaan zo ver dat ze eigen talen voor specifieke ARM implementaties en PowerVR cores maken).

Dat gezegd vraag ik me wel een beetje af wat ARM hier mee wint t.o.v. een andere aankoop. Stel dat ze bijvoorbeeld Imagination Technologies overnemen, dan hebben ze opeens een extreem goede toevoeging aan hun portfolio. SSL is daarentegen slechts een klein stapje gezien je daar alleen wat mee gaat doen als je geen mainstream OS gebruikt, en laat dat nou net zijn waar ARM chips het vaakst mee gebruikt wordenL mainstream OSsen.

[Maurice v/d Zwaan]

Hardwarematige ssl encrypt/decrypt ?

[Anonymoussaurus]

Misschien heb je wel gelijk. Maar ik zelf denk dat het nu nog te vroeg is voordat er massaal hardware van een mobiel gehacked wordt.

[watercoolertje]

SSL gaat ook niet zozeer om de hardware. Maar om het versturen van gegevens in een vorm die tussen de verzender en ontvanger geen waarde heeft om af te vangen...

Als alle SSL nou door een aparte chip kan worden geencrypt/decrypt, dan is dat minder belasting voor de CPU zelf. Nu zal het op high end telefoons geen probleem zijn, maar wat als je lamp een ARM chip krijgt? En je stofzuiger? En waarvan je de status op je netwerk kan uitlezen of zelfs settings kan aanpassen, dan wil ik iig wel dat dat encrypted gaat.

[Reactie gewijzigd door watercoolertje op 27 juli 2024 09:24]

[MSalters]

"Wat als" is niet eens zo hypothetisch. De smartphone chips zijn Cortex-A serie, maar er is ook een Cortex-M serie juist voor low-power diep-embedded toepassingen. Dan moet je denken aan magnetrons, thermostaten en dergelijke. Wil je met het Internet of Things je thermostaat bedienen vanaf je smartphone, dan is SSL wel zo'n goed idee.

[watercoolertje]

Ja vandaar dat ik het heb over die lamp, met inderdaad het internet of things in mijn achterhoofd is het hardwarematig toepassen van encryptie geen slechte zet!

Nu nog een thermostaat die ook daadwerkelijk met je smartphone bedient kan worden zonder connectie naar de maatschappij die dat ding aanbied (dus geen centrale online server zoals NEST of dat ding van Essent/Eneco, en de Nefit Easy geloof ik ook) maar waarmee ik gewoon 1:1 met de thermostaat kan verbinden. Ik sta open voor suggesties, heb nu nog een domme thermostaat die niet eens tijd kan schakelen. En zoek nog voor de winter wat beters.

[Reactie gewijzigd door watercoolertje op 27 juli 2024 09:24]

[analog_]

STM32 heeft al hardware encryptie aan boord, draai je een tiental mbit AES uit. Zie hier. Zo lang je niet meer dan een paar kb/minuut verstuurt kost cryptografie geen drol, zo 1-2-3 uit het hoofd in de orde van 80uJ/16byte. Ergens een master thesis over liggen.

Leuk om te weten is dat PolarSSL minder methodes beschikbaar stelt maar dat deze wel de officiële NLse cryptolibrary is van de overheid.

[Reactie gewijzigd door analog_ op 27 juli 2024 09:24]

[sjongenelen]

Of de arm servers, zoals deze week in het nieuws was.. Webservers met hardware ssl encrypt en decrypt performen wat beter dan de concurrentie

[kdekker]

Met PolarSSL heb je nog geen https, maar slechts de (encryptie) technieken die bij SSL horen.
I.c.m. OpenSSL levert cURL dat. Een chipboer die met PolarSSL aan de gang gaat, moet dus meer code hebben om https te krijgen. En dat past zeer w.s. NIET in de genoemde 64kB (die alleen voor PolarSSL is).

[Anoniem: 601707]

Met OpenSSL heb je ook nog geen HTTPS, HTTPS is iets van een server of client aandient met behulp van een crypto library die dit kan faciliteren.
cURL levert dit ook alleen maar in combinatie met OpenSSL bindings, deze bindings zou je ook prima met PolarSSL kunnen maken.
Zowel Apache als Nginx (2 marktlijders op het gebied van webservers) kunnen uitgerust worden met zowel OpenSSL als PolarSSL

[kdekker]

De auteur van cURL werkt inderdaad alleen samen met OpenSSL. De API van OpenSSL is anders dan die van PolarSSL. Dat zet je niet zomaar over. Mijn opmerking ging slechts over het feit dat je niet genoeg had aan die 64k...

P.s. Marktlijders is wel een ernstig verschijnsel...

[Anoniem: 601707]

https://polarssl.org/kb/how-to/compile-curl-with-polarssl
Weet niet hoe je daar bij komt maar de standaard cURL /configure heeft anders gewoon PolarSSL support....

[kdekker]

Je hebt gelijk (zie ook http://curl.haxx.se/docs/libs.html).

[Faeron]

PolarSSL wordt ook gebruikt in Hiawatha, een webserver van Nederlandse bodem. Gebruikers hebben dankzij PolarSSL Heartbleed lachend aan zich voorbij laten gaan en krijgen met minimale inspannig een hoge score van SSLlabs.

[kdekker]

Heartbleed is meer een beheerdersprobleem dan een coderingsprobleem. Wie bewust (stokoude) compatibiliteit wil handhaven kan met OpenSSL prima uit de voeten. In geval van PolorSSL vermoed ik dat de ontwikkelaar niet eens de mogelijkheid biedt voor het aanbieden van die compatibiliteit. Dat is een keuze van de ontwikkelaar, waardoor een keuze voor de eindgebruiker door komt te vervallen.

Realiseer je wel dat die compatibiliteit er in zit omdat er (mogelijk) nog partijen zijn die het gebruiken. Grote bedrijven als belastingdienst, banken, overheden lopen doorgaans niet voorop in de adoptie van de laatste veiligheidsstandaarden, omdat hun ICT omgeving zo complex is. Bij dat soort clubs geldt 'werkt het' belangrijker is dan 'werkt het veilig'. En als klant van een bank denk je er w.s. over, tenzij dat je iets meer van ICT weet (en bijv. identiteitsfraude).

[Pinkys Brain]

Dit is waarschijnlijk voor mbed os, ik geloof dat ze op het moment axtls gebruiken maar dat is niet zo compleet als polarssl.