Onderzoekers: xml-encryptie is niet veilig
Door een kwetsbaarheid in W3C-standaard xml encryption, een encryptiemethode die toegepast wordt tussen webdiensten, is de standaard niet langer als veilig te beschouwen. Een aantal Duitse onderzoekers wist de beveiliging te kraken.
Xml encryption, een officiële W3C-standaard, wordt met name toegepast bij het uitvoeren van transacties bij financiële instellingen en bedrijven die actief zijn in e-commerce. Onder andere IBM, Microsoft en Red Hat gebruiken de standaard volgens de Duitse onderzoekers verbonden aan de Rühr Universiteit. Zij stellen echter dat de huidige xml encryption-standaard als onveilig moet worden betiteld omdat de data ontsleuteld kan worden.
Twee onderzoekers, Juraj Somorovsky en Tibor Jager, stuurden tijdens de aanvalsmethode versleutelde datapakketjes die zij manipuleerden naar een server. Aan de hand van foutmeldingen van de server wisten zij data die met het des- of aes-algoritme in de zogenaamde cipher block chaining-modus te ontsleutelen. De beveiligingsonderzoekers zullen later dit jaar op de ACM Conferentie in Chicago meer details geven over de aanvalsmethode.
Volgens de onderzoekers is er sprake van een fundamentele kwetsbaarheid in xml encryption en is het probleem lastig te repareren. Daarom zou er gekeken moeten worden naar een nieuwe versie van de xml-standaard.
Reacties (19)
Ik vraag me af of iemand de XML Encryption standaard gebruikt. Dit is de eerste keer dat ik er uberhaupt van hoor.
Wel als ik het artikel mag geloven:
Elke onveiligheid in elke standaard is iets wat opgelost moet worden natuurlijk. Maar ben bang dat dat nooit het geval zal zijn. Daarom natuurlijk ook erg goed dat zulke onderzoeken er zijnXml encryption, een officiële W3C-standaard, wordt met name toegepast bij het uitvoeren van transacties bij financiële instellingen en bedrijven die actief zijn in e-commerce. Onder andere IBM, Microsoft en Red Hat gebruiken de standaard
Volgens die redenatie bestaan een heleboel zaken niet 
Dat is toch ook precies de reden dat de aarde plat is; en als je mij niet gelooft, kijk dan maar is uit het raam! 
Het voordeel van XML is dat je met één 'taal' tussen verschillende platformen kunt communiceren. Dat voordeel vervalt als je er vervolgens een proprietary encryptie voorhangt.
Proprietary? Wat heeft dat ermee te maken? Geëncrypte pakketjes kun je alleen ontcijferen als je de sleutel weet. Het maakt niet uit of de encryptie open of gesloten is.
Het voordeel van open encryptie is dat het algoritme door iedereen geanalyseerd kan worden, zodat de wenselijke eigenschap dat decryptie alleen mogelijk is met de sleutel (iets dat zeker niet vanzelf zo is) ook bevestigd kan worden.
Gesloten encryptie heeft dat voordeel niet. Het kan uiteraard net zo veilig zijn als een open algoritme, maar de kans daarop is kleiner omdat er minder knappe koppen naar hebben gekeken. Er zijn legio tegenvoorbeelden van "security through obscurity" waarbij het geheim houden van een zwak algoritme juist nadelig is.
Het feit dat encrypted XML open is heeft tot nadeel dat hele volksstammen op zoek moeten naar iets nieuws, maar het grote voordeel dat de zwakte ook bij iedereen bekend is en je dus weet wat voor vlees je in de kuip hebt als een server een bepaalde encryptiemethode (niet) ondersteunt.
Er zijn trouwens genoeg andere manieren om XML te versleutelen, zoals andere posters ook aangeven, die ook allemaal op open algoritmes stoelen.
Gesloten encryptie heeft dat voordeel niet. Het kan uiteraard net zo veilig zijn als een open algoritme, maar de kans daarop is kleiner omdat er minder knappe koppen naar hebben gekeken. Er zijn legio tegenvoorbeelden van "security through obscurity" waarbij het geheim houden van een zwak algoritme juist nadelig is.
Het feit dat encrypted XML open is heeft tot nadeel dat hele volksstammen op zoek moeten naar iets nieuws, maar het grote voordeel dat de zwakte ook bij iedereen bekend is en je dus weet wat voor vlees je in de kuip hebt als een server een bepaalde encryptiemethode (niet) ondersteunt.
Er zijn trouwens genoeg andere manieren om XML te versleutelen, zoals andere posters ook aangeven, die ook allemaal op open algoritmes stoelen.
XML-encryptie wordt vooral in de financiele wereld gebruikt. Echter gebruiken veel partijen nog steeds algemene bestands encryptie. Omdat die methode niet alleen XML (nog steeds een zeldzaamheid in de financiele wereld) bestanden worden versleuteld, maar ook EDI en CSV bestanden.
Ik heb XML-encryptie nog niet op webservices gezien. Daarvoor wordt meestal gewoon SOAP over SSL gebruikt en zich in de praktijk bewezen heeft.
Ik heb XML-encryptie nog niet op webservices gezien. Daarvoor wordt meestal gewoon SOAP over SSL gebruikt en zich in de praktijk bewezen heeft.
SOAP is niet echt elegant en er zijn nog al wat mensen die erg ongemakkelijk gaan kijken als je ze vraagt het te implementeren. 
SSL is de meet gebruikte oplossing, veel al in combinatie met een VPN tunnel tussen de verschillende bedrijven als er met externe partijen word gewerkt. De andere optie is een leased line die ook nog wel eens voorbij komt maar dit is uitzonderlijk tegenwoordig zeker ook omdat de kosten hier voor zo hoog zijn en de betrouwbaarheid lager is dan de betrouwbaarheid van het publieke internet, al kun je wel eens waar een deel van de kosten verhalen op de aanbieder van de lijn maar dat helpt de betrouwbaarheid niet.
Hoe dan ook ik heb encrypted XML hier en daar wel eens voorbij zien komen maar ik moet zeggend at in de transport en logistiek hoek maar zeer weinig bedrijven echt voor uit strevend zijn als het op IT aan komt en zeker de grote internationale bedrijven lopen vaak vele jaren (10 of meer is geen uitzondering) achter de feiten aan.
Ik vermoed dan ook dat encrypted XML als de standaard redelijkerwijs te breken is zonder super computers en maanden werk dan zal het waarschijnlijk weer een kwestie zijn van terug vallen op SSL + VPN tot er iets beters is.
SSL is de meet gebruikte oplossing, veel al in combinatie met een VPN tunnel tussen de verschillende bedrijven als er met externe partijen word gewerkt. De andere optie is een leased line die ook nog wel eens voorbij komt maar dit is uitzonderlijk tegenwoordig zeker ook omdat de kosten hier voor zo hoog zijn en de betrouwbaarheid lager is dan de betrouwbaarheid van het publieke internet, al kun je wel eens waar een deel van de kosten verhalen op de aanbieder van de lijn maar dat helpt de betrouwbaarheid niet.
Hoe dan ook ik heb encrypted XML hier en daar wel eens voorbij zien komen maar ik moet zeggend at in de transport en logistiek hoek maar zeer weinig bedrijven echt voor uit strevend zijn als het op IT aan komt en zeker de grote internationale bedrijven lopen vaak vele jaren (10 of meer is geen uitzondering) achter de feiten aan.
Ik vermoed dan ook dat encrypted XML als de standaard redelijkerwijs te breken is zonder super computers en maanden werk dan zal het waarschijnlijk weer een kwestie zijn van terug vallen op SSL + VPN tot er iets beters is.
Of je zou kunnen kijken of je kan overstappen naar een ander standaard, zoals JSON:Volgens de onderzoekers is er sprake van een fundamentele kwetsbaarheid in xml encryption en is het probleem lastig te repareren. Daarom zou er gekeken moeten worden naar een nieuwe versie van de xml-standaard.
Bron: http://en.wikipedia.org/wiki/JSONJSON is promoted as a low-overhead alternative to XML as both of these formats have widespread support for creation, reading and decoding in the real-world situations where they are commonly used.
.........
XML can be used to describe structured data and to serialize objects. Various XML-based protocols exist to represent the same kind of data structures as JSON for the same kind of data interchange purposes. When data is encoded in XML, the result is typically larger in size than an equivalent encoding in JSON, mainly because of XML's closing tags.
Hoewel JSON in veel gevallen wat voordelen heeft wat betreft overhead en vrijwel net zo goed ingeburgerd begint te raken raakt je opmerking natuurlijk kant noch wal hier. Er zit een fout in de encryptie van de xml-standaard, dat maakt de niet-beveiligde variant niet zomaar nutteloos.
JSON heeft namelijk geen gestandaardiseerde encryptie en is dan ook niet zomaar een alternatief. Sterker nog, het zal een stuk ongustiger zijn om ook nog naar JSON over te stappen doordat je op die manier niet enkel de encryptielaag moet vervangen maar ook de verdere afhandeling van de data, meer werk dus zonder direct voordeel.
JSON heeft namelijk geen gestandaardiseerde encryptie en is dan ook niet zomaar een alternatief. Sterker nog, het zal een stuk ongustiger zijn om ook nog naar JSON over te stappen doordat je op die manier niet enkel de encryptielaag moet vervangen maar ook de verdere afhandeling van de data, meer werk dus zonder direct voordeel.
[Reactie gewijzigd door Leftblank op maandag 24 oktober 2011 15:19]
Ik heb het ook niet over de niet-beveiligde variant van XML. Ik reageer alleen maar op het volgende stukje in het nieuws:
Als je gebruik maakt van deze XML-encryptie, dan moet je het dus sowieso vervangen.Daarom zou er gekeken moeten worden naar een nieuwe versie van de xml-standaard.
Als het om compactheid gaat ga dan voor ASN.1
Conversie tussen ASN.1 en XML en terug kan standaard met een XML schema file.
Conversie tussen ASN.1 en XML en terug kan standaard met een XML schema file.
Ik neem aan dat je dit sarcastisch bedoeld?
ANS.1 is vreselijk om te leren, en kan echt alleen door computers worden uitgelezen.
XML heeft als voordeel dat gewoon tekst en daarom direct leesbaar.
Kunnen ze niet gewoon het encryptie algoritme veranderen?
Ik lees op Wikipedia aes tot 256 bit gaat, als dit je aantal verhoogd wordt het al wat moeilijker volgens mij.
Edit: 265 -> 256
ANS.1 is vreselijk om te leren, en kan echt alleen door computers worden uitgelezen.
XML heeft als voordeel dat gewoon tekst en daarom direct leesbaar.
Kunnen ze niet gewoon het encryptie algoritme veranderen?
Ik lees op Wikipedia aes tot 256 bit gaat, als dit je aantal verhoogd wordt het al wat moeilijker volgens mij.
Edit: 265 -> 256
[Reactie gewijzigd door s.stok op dinsdag 25 oktober 2011 13:00]
Maar 'de xml-standaard' slaat hier op de W3C standaard xmlenc-core , niet op de W3C standaard die XML zelf beschrijft, waarvoor JSON een alternatief zou zijn.
Je trekt een conclusie uit zijn verband. Leftblank heeft wel gelijk.
Met de zinssnede "een nieuwe versie van de xml-standaard" wordt er gedoeld op de encryptiemethode van XML. Niet op XML zelf, zoals jij nu suggereert.
XML is in de basis goed genoeg, het moet nu 'alleen' anders beveiligd worden. En gelukkig gebeurd dat ook al in de financiële wereld. Waar dat nu niet gebeurd, dient men na te denken hoe het wel goed beveiligd kan worden, bijvoorbeeld via SSL. Ook niet zaligmakend, wel moeilijker kraakbaar makend.
Maar als mijn bedrijf nu alles wat ze in XML hebben staan om moeten gooien naar JSON, dan kan de tent bij wijze van spreken haast wel gesloten worden. Dat is een hele dure grap. Dan moet er dus echt wel een business case achter zitten en die is er hier niet, want er zijn andere geschikte mogelijkheden om de datastromen te beveiligen.
Die ook toegepast moeten worden als je wel zou overstappen naar JSON. Oftewel die overstap biedt geen voordelen tegenover blijven zitten op XML. Dus gebeurd het niet.
Met de zinssnede "een nieuwe versie van de xml-standaard" wordt er gedoeld op de encryptiemethode van XML. Niet op XML zelf, zoals jij nu suggereert.
XML is in de basis goed genoeg, het moet nu 'alleen' anders beveiligd worden. En gelukkig gebeurd dat ook al in de financiële wereld. Waar dat nu niet gebeurd, dient men na te denken hoe het wel goed beveiligd kan worden, bijvoorbeeld via SSL. Ook niet zaligmakend, wel moeilijker kraakbaar makend.
Maar als mijn bedrijf nu alles wat ze in XML hebben staan om moeten gooien naar JSON, dan kan de tent bij wijze van spreken haast wel gesloten worden. Dat is een hele dure grap. Dan moet er dus echt wel een business case achter zitten en die is er hier niet, want er zijn andere geschikte mogelijkheden om de datastromen te beveiligen.
Die ook toegepast moeten worden als je wel zou overstappen naar JSON. Oftewel die overstap biedt geen voordelen tegenover blijven zitten op XML. Dus gebeurd het niet.
leuk is dat. ipv dat ze een bedrijf hacken, hacken ze gewoon de hele technologie. Er wordt zelfs informatie gegeven over hoe een hack in zijn werk gaat EN er wordt een aantal bedrijven genoemd die er gebruik van maken. vraag me af of dat zo slim is.
in ieder geval kunnen ze nu niet aangeklaagd worden door één bedrijf dat zichzelf voor gek vindt staan.. dat dan weer wel. (wat leven we toch in een vreemde wereld)
in ieder geval kunnen ze nu niet aangeklaagd worden door één bedrijf dat zichzelf voor gek vindt staan.. dat dan weer wel. (wat leven we toch in een vreemde wereld)
[Reactie gewijzigd door discy op dinsdag 25 oktober 2011 09:27]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
