Twitter schroeft bescherming tegen onderscheppen data op

Twitter heeft de versleuteling van zowel zijn api als zijn website opgeschroefd. Vanaf nu is er ondersteuning voor perfect forward secrecy ingebouwd. Het onderscheppen van data heeft daardoor minder zin, doordat er wordt gewerkt met tijdelijke sleutels.

Veel landen, waaronder de Verenigde Staten maar ook bijvoorbeeld Noord-Korea, China en Iran, slaan grote hoevelheelheden versleuteld internetverkeer op, in de hoop het later te kunnen kraken. Dat heeft bij Twitter nu minder zin: als in de toekomst de cryptografische sleutel wordt bemachtigd, bijvoorbeeld via een gerechtelijk bevel of een hack, kan in het verleden onderschept internetverkeer niet meer worden ontsleuteld.

Twitter heeft daartoe ondersteuning voor perfect forward secrecy ingebouwd, zo legt een beveiligingsmedewerker van de microbloggingdienst uit. Daarbij wordt gebruikgemaakt van tijdelijke sleutels. Wordt de sleutel in de toekomst bemachtigd, dan kan daardoor enkel recent verkeer worden ontsleuteld: verkeer uit het verleden heeft een andere sleutel gebruikt, die dan al is verwijderd. De functionaliteit is zowel op de website als op de api ingeschakeld, waardoor ook gebruikers van Twitter-apps beter zijn beschermd.

Het sociale netwerk maakt gebruik van het Diffie-Hellman-protocol. Voor circa 75 procent van de gebruikers wordt de elliptic curve-variant van Diffie-Hellman gebruikt, die onder andere een minder zware wissel op de server trekt. Een kwart van de clients ondersteunt die variant echter niet; voor die clients wordt de discrete logarithm problem-variant van Diffie-Hellman gebruikt. Die gebruikt veel meer rekenkracht. Overigens biedt Diffie-Hellman geen mogelijkheid tot authenticatie: daarvoor zal dus een aanvullend protocol, bijvoorbeeld het veelgebruikte RSA, moeten worden ingezet. Bij het versleutelen van verbindingen is het namelijk ook belangrijk om de identiteit van de ander vast te stellen; anders zouden anderen zich kunnen voordien als de ontvanger en de data ontsleutelen.

In de opzet van Twitter wordt elke vijf minuten een nieuwe sleutel gegenereerd door een server die daarvoor speciaal is opgezet. De servers die verkeer met gebruikers afhandelen, loggen elke vijf minuten via ssh in op die server om de nieuwe sleutels te downloaden. Die worden niet opgeslagen, maar worden met behulp van tmpfs ingeladen in het geheugen van de servers, om te voorkomen dat bijvoorbeeld forensische experts de sleutels kunnen achterhalen. Tmpfs is een bestandssysteem voor het tijdelijk in het geheugen 'opslaan' van bestanden.

Daarbij zijn voor het bestandssysteem geen swap-partities geconfigureerd: in dat geval zouden de sleutels per ongeluk toch op het non-volatiele geheugen terecht kunnen komen. Elke frontend-server onthoudt zowel de huidige sleutel als de vorige twee sleutels. Mochten inlichtingendiensten daarmee toch sleutels in handen krijgen, dan kunnen ze dus enkel verkeer van de laatste vijftien minuten ontsleutelen.

Twitter stelt dat perfect forward secrecy de nieuwe norm voor internetverkeer zou moeten worden. Medewerkers zeggen tegenover The New York Times enkele maanden nodig te hebben gehad om de technologie te implementeren. Dat was deels te danken aan Google, dat als eerste grote internetbedrijf perfect forward secrecy inzetten. Google deelde zijn ervaringen bij het inzetten van de technologie met de beveiligingscommunity.

Een beveiligingsmedewerker van Twitter zegt tegenover de krant dat hij perfect forwards secrecy al langer wilde implementeren, maar dat de rest van het bedrijf daar pas oren naar had na de onthullingen van NSA-klokkenluider Edward Snowden. "Toen bleek dat er echt organisaties zijn die op grote schaal versleutelde data onderscheppen", zegt hij.

Door Joost Schellevis

Redacteur

23-11-2013 • 10:14

37 Linkedin

Reacties (37)

37
36
23
1
0
5
Wijzig sortering
Twitter Inc. is based in San Francisco and has offices in New York City, Boston, San Antonio and Detroit
Twitter is een amerikaans bedrijf en valt dus onder US wetgeving. Wat mij betreft zegt dat genoeg.
Ik geloof er geen barst meer van dat de NSA en cohorten geen rechtsstreeks lijntje hebben liggen die de versleuteling compleet buitenspel zet.

Nooit gedacht dat ik een alu hoedje mentaliteit zou krijgen, helaas heeft de realiteit daar wel voor gezorgd.
Ach, ze krijgen dadelijk gewoon de verplichting om de random sleutels te archiveren. Daarmee is het probleem voor de NSA opgelost. Als je de communicatie tussen clients wilt verbeteren, is gebruik van OTR een goede eerste stap. Maar dan kan twitter de data zelf ook niet meer inzien, denk niet dat ze dat willen laten gebeuren.
Er is nogal een verschil tussen een gerechterlijk bevel* om data specifiek van een persoon te overhandigen, en het gigantische cybersleepnet dat de NSA gebruikt om van iedereen data te verzamelen. Dat laatste maakt Twitter nu praktisch onmogelijk. Als je echt wat te verbergen hebt moet je je eigen maatregelen treffen zoals Dorank noemt.

*: wat je van een geheime rechtbank zoals de FISC vindt is een tweede.

[Reactie gewijzigd door Rafe op 23 november 2013 18:35]

Deze encryptie wordt ingezet voor de data overdracht van de Twitter server naar de client.
Dat staat verder los van de directe database toegang van de NSA (er vanuitgaande dat er zoiets is).
Wellicht dat de verbinding geëncrypt wordt, maar alle data blijft daarbij nog wel toegankelijk.
Deze hoeft namelijk niet onderschept te worden als er al directe toegang is.
En dat er nog vele bedrijven hun voorbeeld mogen volgen ! :)

Ontopic : Ze zouden natuurlijk ook memcached kunnen gebruiken, wat me misschien wel geschikter lijkt dan tmpfs, aangezien permission built in zit.

[Reactie gewijzigd door TT17 op 23 november 2013 10:21]

Ik zie geen enkel voordeel in het gebruiken van memcached boven tmpfs om de sleutels in op te slaan. Het wordt enkel lokaal gebruikt na het downloaden van de sleutel via ssh. Bovendien heeft tmpfs ook gewoon permissies ingebouwd. Lijkt me dat enkel het proces dat de SSL-offloading verzorgt toegang heeft tot deze bestanden.
Sterker nog, met tmpfs kun je ook gebruiken van selinux contexts en Access Control Lists. Een veel beter alternatief dan memcached!
Maar kan tmpfs de sleutels ook in CPU registers opslaan? Want is dat echte security.
Als je het in RAM opslaat kan je dat enkele seconden na de server uit te zetten en het RAM gekoeld te hebben nog prima uitlezen, of anders met een DMA attack onderscheppen.
Als je het in RAM opslaat kan je dat enkele seconden na de server uit te zetten en het RAM gekoeld te hebben nog prima uitlezen
Het is ook echt mogelijk om binnen enkele seconden een server uit een rack te schroeven en die volledig te koelen tot de vereiste temperaturen...
of anders met een DMA attack onderscheppen.
Moderne hardware heeft daar bescherming tegen d.m.v. o.a. een IO MMU dus als de server recent genoeg is, is ook dat een moot point
Misschien moet je je eerst inlezen in de materie en daarna pas reageren....

Ja, het is mogelijk om een server al draaiend te koelen, ja het is mogelijk om hem al draaiende te hot-rebooten zonder het RAM te wissen, zonder koelen en dan alsnog 90% van de data te lezen.

( http://en.wikipedia.org/wiki/Cold_boot_attack en bijv.
http://www.forensicswiki.org/wiki/Tools:Memory_Imaging )


Moderne hardware is JUIST vatbaar voor DMA attacks, daar is bijvoorbeeld Inception voor bedacht om maar een van de vele opties te noemen.(http://www.breaknenter.org/projects/inception/)
Nee, aangezien tmpfs een filesystem is dat heel toevallig RAM gebruikt als blockdevice. Wil je de sleutel verder beveiligen dan moet je luks/dm-crypt of loop-aes gebruiken met random keys (of bv encfs/ecryptfs in userland). Of die random sleutel veilig wordt opgeslagen in de kernel zou ik niet weten, mogelijk staat die dus ook weer open voor een deep freeze attack.
Ik weet dat LUKS (die dm-crypt als backend heeft) het in RAM doet toen ik het nog in de 2.6 branch gebruikte, maar er toen al patches voor register-storage voor keys waren. Misschien zijn die nu in upstream geïntegreerd en al default...

Alle encryptie waarbij sleutels in het RAM staan is eigelijk zinloos als je tegen echte hacks beschermd wil zijn, om dat het simpelweg altijd uit te lezen is met fysieke toegang.

Natuurlijk kan je je ook beperken tot bepaalde niveau's, zoals datacenter traffic on-sniffbaar maken, maar lager dan dat niet. Dan zit Twitter wel goed.
Dat kun je natuurlijk alleen maar toejuichen, extra beveiliging kan geen kwaad. Zeker als je in een land zit waar alles wat je zegt verkeerd kan zijn. Maar ook idd om de NSA toch maar weer voor te zijn. Nou maar hopen dat er toch niet ergens een backdoor zit
Dit kan wel degelijk kwaad. Dit zet NSA er enkel maar toe aan om nog grotere investeringen te doen in apparatuur en research.
Ja maar zo kan je natuurlijk alles afdoen. Waarom je huis op slot doen, als de inbreker binnen wil komen lukt dat toch wel ?! Het is natuurlijk niet alleen de NSA he. Ook tegen gewone hackers of andere (misschien minder goed funded / georganiseerde) organisatie's.
Niks doen is zeker niet goed en als ze echt iets te weten willen komen dan komen ze er achter ook. Alleen de hoeveelheid tijd en moeite die ze er dan in moeten stoppen kan dan nog een reden zijn om het niet te doen.
Gelukkig hoeven wij dat niet te betalen. En knappe jongens, die Amerikanen, als ze nóg meer onzin weten te kopen met een schuld die hoger ligt dan het BNP.
Twitteraars gooien (een deel van) hun hele leven met Tweets op internet ...... waarom zou dat ueberhaupt versleuteld moeten worden ? Als het niet voor iedereen is, stuur dan een versleuteld document.
Twitteraars gooien (een deel van) hun hele leven met Tweets op internet ...... waarom zou dat ueberhaupt versleuteld moeten worden ? Als het niet voor iedereen is, stuur dan een versleuteld document.
Omdat sommige mensen dat onder een pseudoniem doen om te voorkomen dat ze worden opgepakt door de gedachtenpolitie. Door deze versleuteling kan de bron minder makkelijk ontdekt worden.
Het moet eerst slechter gaan voor het beter gaat. Ik zie toch steeds meer oplossingen komen wat ons burger veiliger maakt.
Chapeau voor Twitter!! Als ik het goed heb zijn ook zij diegene die actief het opvragen van gegevens tegenwerken en er zo min mogelijk aan mee werken (elke keer aanvechten bij de rechter). Mooi dat een dergelijk groot bedrijf toch zo'n aandacht besteedt aan de privacy van zijn gebruikers.
Twitter is toch een Amerikaanse bedrijf en die hebben altijd te maken met de Patriot Act dus het is een illusie om te denken dat er hier geen backdoor voor is. Het is allemaal damage control meer niet.
Toevallig net de nieuwste C'T van december aan het doorlezen. Staat een mooi stuk in over perfect forward secrecy. In de conclusie vraagt men zich af wanneer andere bedrijven naast Facebook en Google volgen. Ik denk dat we Twitter dus aan het lijstje kunnen toevoegen.
<quote>
als in de toekomst de cryptografische sleutel wordt bemachtigd, bijvoorbeeld via een gerechtelijk bevel of een hack, kan in het verleden onderschept internetverkeer niet meer worden ontsleuteld.
</endquote>

'NSA wilde meer bevoegdheden'

<quote>
Daarnaast was de dienst van plan om met 'commerciële relaties' invloed te willen uitoefenen op bedrijven die producten met encryptie maken
</endquote>

Jammer joh! Want die encryptie kan/is inmiddels voorzien van backdoors waardoor de sleutel in zijn geheel niet nodig is.
Anoniem: 425037
24 november 2013 12:07
Goede zaak maar als, al dan niet via een gerechtelijk bevel, een amerikanse overheids dienst inzage in de gegevens van Twitter wil krijgen is een beetje versleuteld internet verkeer echt geen probleem.
Ze vragen dan toegang tot de 'database' van alle tweets, rechtstreeks.

Waarom zou je nog internet verkeer willen decrypten als je gewoon in de gegevens kun garsduinen?

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee