Google brengt Confidential VM's voor Cloud uit die data in geheugen versleutelen

Google gaat in zijn Cloud-dienst een nieuw soort virtual machines aanbieden. De Confidential VM's zijn bedoeld om data versleuteld in het geheugen op te slaan. Confidential VM's draaien op AMD's Epyc-cpu's.

De Confidential VM's zijn een bètafeature binnen het nieuwe Confidential Computing-platform. Google wil er daarmee voor zorgen dat data niet alleen at-rest en tijdens de verzending wordt versleuteld, maar ook bij het indexeren en het opslaan in het werkgeheugen. Google kondigde de Confidential VM's deze week aan tijdens het virtuele Google Next-evenement.

Confidential VM's zijn virtuele machines in Google Cloud waarbij de data dus ook buiten de cpu's om wordt versleuteld. De vm's draaien niet op Intel Xeon-processors, zoals de meeste Google Cloud-applicaties, maar op de tweede generatie AMD Epyc-cpu's. De machines maken gebruik van de Secure Encrypted Virtualization-enclave van de socs.

De encryptiesleutels worden door de hardwarematige Secure Processor gegenereerd en zijn daarom niet te exporteren. Volgens Google kunnen bestaande Cloud-workloads die in standaard vm's draaien, gemakkelijk worden overgezet naar Confidential VM's.

Reacties (39)

Een vergelijking met bijvoorbeeld Azure Confidential Computing zou wellicht een nuttige toevoeging zijn. https://azure.microsoft.c...ons/confidential-compute/

Dat dus. Voeg daar aan toe dat je via SysMon + Security Center ook nog kunt monitoren en je hebt een veel completere oplossing. Naast het feit dat Azure Confidential Compute al eventjes GA is.

Als ik het goed begrijp heeft de host dus geen inzage meer in het geheugen van zijn guests. Ontzettend gaaf!

Maar hoe weet je zeker dat je op een confidential VM draait. Zou je dat kunnen verifiëren vanuit de vm zelf? Met Zekerheid?

Als het gevaar de host is... Dan ben je toch nooit veilig?

Inderdaad, dat weet je niet, en als het echt zo confidential is, waarom zou je de data bij een derde partij op machines zetten, is ook een goede vraag.

Maar een extra laag security, is een extra laag, het zal gebruik van google VMs niet onveiliger maken.

Exact, maar dus wel een soort van.. gimmick. Welke vooral leuk klinkt en misschien voor spyware op de host server iets effect heeft.

Precies, en ook naar mijn idee een marketing truuk. Wellicht dat de 'Shielded VMs' niet zo goed verkochten, hebben ze er een extra feature aangehangen en nieuwe naam, en dan kan marketing afdeling weer wat 'nieuws' promoten. De shielded VMs hadden al bescherming tegen root en bootkits.

Als het zo confidential is dan kun je het als nog goed bij een derde partij hosten. Je moet je op een bepaald moment de vraag stellen of het de moeite waard is niemand te vertrouwen. Immers een eigen server kan ook van uit de fabriek al spyware bevatten. Een eigen server ontwikkelen is een leuk idee maar best lastig, en zelfs als je dat doet als je het ding niet zelf in elkaar zet... en dan alle onderdelen zouden eventueel ook door een derde partij aangepast kunnen zijn dus...

100% veilig gaat toch niet lukken maar. Google heeft er zeer weinig baat bij om jouw data uit te lezen immers hun cloud staat of valt met het vertrouwen dat mensen en bedrijven hebben in hoe Google met hun belangrijke systemen en data omgaat.
Om die reden zou ik ook niet zo snel me zorgen maken over of de host wel veilig is, alsje daar aan twijfelt dan moet je hoe dan ook niet in een cloud draaien.
Als je er van uitgaat dat de host veilig is dan kun je je altijd nog zorgen maken over andere VM's die de host draait en hoe het geheugen schoon gemaakt wordt als het van de een naar de andere VM verschoven wordt. Ook kan ik me goed voorstellen dat je bepaalde processen niet op de zelfde machine wilde draaien omdat een deel van de data die je verwerkt zeer gevoelig is en je simpel weg de luxe niet hebt om andere binnen de organisatie daar mee te vertrouwen.
Er zijn bijvoorbeeld bepaalde clearance levels nodig om tapping data binnen een ISP te bekijken en dit mag om die reden niet in een door "normaal" personeel toegankelijke database worden opgeslagen.

Ik kan me zo voorstellen dat (AWS Gov Cloud is een mooi voorbeeld) bepaalde groepen eisen stellen die je alleen kunt in willigen door een aparte omgeving op te zetten en er zullen dus ook organisaties zijn die eisen dat data hoe dan ook nooit decrypted is buiten de CPU om.
Juist om dit soort partijen tegemoet te komen zal Google deze oplossing nu bieden en waarschijnlijk als de ervaringen goed zijn (Intel een soort gelijke oplossing bied) en de prestaties er niet te veel onder lijden kan ik me helemaal voorstellen dat dat langzaam maar zeker de standaard zal worden voor alle clouds. Het is simpel weg een extra veiligheid die je in kan bouwen om te voorkomen dat mensen data bekijken waar ze de bevoegdheid niet toe hebben.

Dit is natuurlijk niet een volledige oplossing dat zou immers vereisen dat je een key per process gebruikt in plaats van een key per VM maar het is wel een stap in de goede richting. In de toekomst verwacht ik dat het OS automatisch een per process key aanvraagt bij een secure enclave in de CPU zodat ieder process automatisch een eigen sleutel heeft voor geheugen toegang en alleen in het geval van shared memory een sleutel door meerdere processen gebruikt zal kunnen worden.
Als je dat goed doet is dit geheel transparant voor de processen en heeft het geen of minimale impact op de performance waardoor het gewoon een gegeven is dat je hoe dan ook nooit kan zien wat een ander process in het geheugen heeft geschreven.

Exact dit. Zo'n 'alles is encrypted' mandaat doet relatief weinig als de implementatie en de sleutels allebei in handen zijn van de partij die de data op slaat. Dit komt ook af en toe naar voren bij security audits; ik zie bedrijven grof geld betalen voor een bureaucratisch vinkje terwijl de sleutel gewoon naast de kluis ligt.

Je opslag kan je altijd zelf versleutelen. Dit is voornamelijk interessant om ervoor te zorgen dat een lek in de host niet direct resulteert in datalekken van de guest. Als meer dan dat wordt het volgens mij ook niet gemarket?

Als een host gecomprimeerd is, dan zijn de guest instanties theoretisch gezien ook gecomprimeerd. Dan kun je gewoon de beveiligingssleutels uit de guest lezen. Zelfs al gebruik je een IO brug waardoor de guest niet direct toegang heeft tot de opslag... dan kan de gecomprimeerde host zich net zo goed voordoen als guest.

In dit geval is de sleutel in handen van de amd secure processor.

De encryptiesleutels worden door de hardwarematige Secure Processor gegenereerd en zijn daarom niet te exporteren.

De overgenome host kan dan een ander virtueel systeem laten crashen, en als het virtueel herstart word faken dat de VM in versleuteld RAM mode draait.

Natuurlijk ziet de VM guest dit als een spontane reboot en zou je er achter moeten gaan maar als je niet snel genoeg bent zijn de autostart services/applicaties al gestart en zijn mensen alweer bezig met transacties die dan worden onderschept.

Dus mischien in geval van reboot niet automatisch starten

Je kan wel aan de cpu info zien dat de SEV feature wordt ondersteund, maar hoe checken of het actief is weet ik niet. Kan je enkel op hypervisor niveau denk ik

Het dekt met name het gevaar van andere VMs.

Als een andere VM een zero-day heeft waarmee hij een VM escape kan uitvoeren is het hiermee heel veel moeilijker om ongedetecteerd het geheugen van andere VMs uit te lezen.

Zonder SEV of vergelijkbare techniek kan een VM na de escape enkel proberen geheugen te lezen, en deze daarna binnen de oorspronkelijke VM verwerken/versturen. Met SEV moet de VM na de escape instellingen in de hypervisor gaan wijzigen, waarbij dat een hoop makkelijker te detecteren is.

Als je echt een evil hypervisor hebt, waarbij Google moedwillig de VMs uitleest, blijft dit lastig te detecteren vanuit de VM zover ik weet. Het probleem van virtuele hardware is dat niks te vertrouwen is.

[Reactie gewijzigd door Niet Henk op 15 juli 2020 12:09]

Het is een specifieke instance type die je moet aangeven bij het opstarten van je VM. Dus je weet wanneer je een confidential VM draait. Ook vanuit de VM zelf, meta data opvragen van je huidige instance type.

Maar hoe weet je zeker dat je op een confidential VM draait. Zou je dat kunnen verifiëren vanuit de vm zelf?
Ik denk dat dit 'transparant' is voor de VM zelf. Een VM hoeft ook helemaal niet te weten dat deze 'virtueel' is. Je hebt echter gewoon een management interface in GCP waar je dit kunt configureren.

Met Zekerheid? Als het gevaar de host is... Dan ben je toch nooit veilig?
Omdat die zaken, zoals bij ieder redelijk bedrijf, gewoon getoest en geaudit worden. Dit gebeurd door een extern en onafhankelijk onderzoeks bedrijf of bijvoorbeeld onze overheid / EU (die huurt er echter weer iemand voor in).

Zie hier een lange lijst compliance standaarden waar men aan voldoet. Uiteraard hebben alle grote cloud leveranciers soortgelijke compliancy audits.

De test zou wat mij betreft betrekkelijk eenvoudig zijn:
- de cpu moet een amd-epyc zijjn
- de Secure-Encrypted-Virtualisation-Enclave moet er op zitten en in gebruik zijn.
Natuurlijk zijn dit soort zaken te neppen en zo.
Uiteindelijk, als de afscherming zo'n issue is, dan zijn dat genoeg redenen om niet naar een externe hosting partij te gaan.

En besef: "The Cloud" bestaat niet, het is gewoon iemand anders zijn computer.

Kan de host normaliter makkelijk het geheugen van vm uitlezen?

Ja. De host bepaald immers onder welke sandbox instellingen de guest draait, en de host kan deze instellingen elk moment aanpassen zonder dat uberhaupt aan de guest te vertellen. Je kunt wel formeel alles gescheiden houden, maar als host kun je ook op kernel-niveau drivers toevoegen waarmee je alles inzichtelijk kunt maken.

Dat AWS, Azure en GCP niet door jouw data gaan, is puur een contractuele belofte... geen technische onmogelijkheid.

Leuke toevoeging... als je in jouw EC2 instantie lsmod in typt, dan zie je precies tot welke kernel-modules jouw guest toegang heeft. Ik kom uit op 53 modules. Als ik dit op mijn Fedora Linux desktop doe, dan kom ik uit op 183

[Reactie gewijzigd door Eonfge op 15 juli 2020 12:14]

Technisch zullen de engineers nog steeds toegang hebben. Gezien er doorgaans wel een agent draait op de vm om deze aan te sturen, alleen worden de activiteiten van die agent wel bijgehouden dus kan er worden gecontroleerd wie wat gedaan heeft. (Althans bij Azure, maar ik vermoed dat dit hetzelfde is bij andere cloud providers)

Ik denk dat deze oplossing eerder bedoeld is om potentiële aanvallen van andere guests te voorkomen. Dat kon tot nu toe enkel door een dedicated host te huren, wat best duur.

Dank

Leuke toevoeging... als je in jouw EC2 instantie lsmod in typt, dan zie je precies tot welke kernel-modules jouw guest toegang heeft.

Guest of host?

Ik voer lsmod uit in de EC2 instantie die ik heb. Binnen die EC2 instantie draaien enkele dockers en VMs, maar EC2 zelf is ook een VM. 90% van alle cloud-computing is virtual-machine lasagna, dus en waar ik zelf in die laag zit, kan ik jou niet vertellen.

Maar waarom is het een probleem dat de host in het geheugen van de guest kan kijken? Waarom is het zo geniaal dat dat hiermee niet meer kan?

Het is VEEL belangrijker dat de guests niet in *elkaars* geheugen kunnen kijken, want de mogelijke malware zit in de guests. Je mag er vanuit gaan dat de host veilig is.

Als de host gekraakt wordt is de guest op deze manier nog steeds veilig voor snooping.

Dan heb je het over een kwaadwillende derde. Maar Google kan zelf ook in geheugen spieken. Het is immers een advertentiebedrijf dat obv datamining met allerlei aannames hun advertenties duurder kan maken voor de adverteerders. Dus als het om Google gaat, moet je niet alleen derden als mogelijke malefactors zien.

Hoe gaat het dan als VM naar andere host gaat? Want als alles encrypted is met niet exported sleutels kan met een crash van de host ook de staat van de VM niet ge-exporteerd worden?

Misschien een non-issue voor de beoogde markt, maar voor mainstream wel een ding.

Bij de grote cloud providers worden vms niet tussen hosts verplaatst. Als er issues zijn met een host krijg je daar een melding van. Het is dan aan jou om die vm te stoppen en te starten. Dan start dat ding automatisch op een gezonde host weer op. Gaat een host stuk dan word je vm weer gestart op een gezonde host.

Dus daar heb je het probleem niet om die encryptie over hosts te delen.

[Reactie gewijzigd door Pikkemans op 15 juli 2020 12:16]

De gasten verplaatsen gewoon van host naar host als dat onderdeel is van de omgeving. De sleutels zijn dan misschien niet te exporteren maar ze zijn dan niet host-gebonden maar omgeving-gebonden: Elke host in die omgeving kan met de sleutels werken. Er zak vast een centrale sleutel-bewaarder zijn.

Wie verhuist er nog een VM? Nieuwe spinnen en kubernetes doet de rest...

De overige 99% van de wereld die geen k8s gebruikt.

Dat is sterk afhankelijk van je workload. VM's die ingezet worden voor VDI en RDS oplossingen hebben lopende usersessies. Die users wil je niet van hun sessie kicken, maar moeten gewoon seamless kunnen doorwerken. Het kunnen inzetten van vmotion om ongehinderd onderhoud te kunnen doen aan een host, of voor Dynamic Resource Scheduling is dan ideaal.

Iedereen die geen downtime wilt op vm niveau.

Als de encryptie code in de CPU word opgeslagen, hoe ga je dan redundantie opbouwen als de server wegvalt? Een andere server kan de taak (De VM) namelijk niet overnemen door de missende key.

De versleuteling en ontsleuteling is door de cpu. De gebruikte sleutel komt van een centrale sleutelbewaarder. Zolang een host bij de sleutel kan en mag, zal ze met die sleutel kunnen werken. Gasten gaan binnen de host zonder problemen van cpu naar cpu. Het is tussen de sleutelbewaarder en de hosts of/hoe/wanneer/waarom een host gebruik mag maken van een sleutel.

De host kan het geheugen ook ontsleutelen. Dat is immers wat de hypervisor moet doen om de guests werkend te houden.

M.a.w. versleuteling is compleet nutteloos als versleuteling en ontsleuteling op dezelfde plek en op hetzelfde moment (kunnen) plaatsvinden.

Ik mis wel iets in de artikel...
maar wat betekent het voor Google? Krijgt Google daarvoor iets terug?

Meer geld, meer klanten en betere naam als veilige public cloud provider? Deze confidential VM's zullen vast duurder zijn dan normale instances, en er is vraag naar in de markt...