bloghoved ole tange

Google lancerer kryptering af RAM

Google Cloud krypterer al internettrafik og al storage for deres virtuelle maskiner. Men indtil nu har rammen i deres virtuelle maskiner været ukrypteret.

Det ændres nu: Man kan nu vælge at få rammen krypteret, så data kun er dekrypteret i CPU’en.

Se: https://cloud.google.com/confidential-computing

Det er uden tvivl en god ting. Det må gøre det sværere for en angriber at få adgang til rammen. Hvis ens virtuelle maskine kører på samme fysiske hardware som en angriber, så kan en angriber i dag benytte RAMBleed til at tilgå data overalt i rammen – herunder rammen for andre VM’er. Hvis en angriber alene kan tilgå kryptede data, så bliver det problem mindre.

Det ændrer ikke på, om Google kan tilgå dine data: De vil altid uden dit vidende kunne lave et snapshot af hele din virtuelle maskine – inkl CPU og dermed have adgang til alle dine data, og give dem videre til hvem de nu har en aftale med.

Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Dave Pencroof

"Det ændrer ikke på, om Google kan tilgå dine data: De vil altid uden dit vidende kunne lave et snapshot af hele din virtuelle maskine"

Hvordan er det anderledes end at det offentlige gør brug af vores persondata uden at vi får noget at vide, med påstande om at det er til fælles bedste. Mens domstolen siger NEJ til visning af udsendelse som viser super elendige forhold på plejehjem, med den totalt modsatte begrundelsen, at det er krænkende for X, mens man rimeligt let ville kunne sløre den udsatte person i de prekære situationer, og evt med skuespillere vise det rimeligt detaljeret. Vi ved hvor vi har Alphabet, men ved vi hvor vi har det offentlige DK ????

Have a very nice weekend, you all !

  • 4
  • 6
#4 Ole Tange Blogger

Rowhammer og rambleed kan forhindres. Google kan bare købe nyere hardware der implementere mitigation.

Uden at kende detaljerne så virker det som om, at det netop er det, de har gjort. Så vidt jeg kan lure, så er RAM kryptering kun understøttet på nyere Ryzen processorer, så hvis du klikker checkboxen af, bliver din VM startet på en sådan processor.

Jeg har ikke kunnet finde nogen, der forklarer, om der er en performance (eller en strøm) penalty. Men jeg kan umuligt forestille mig, at det ikke koster noget i enten strøm eller performance.

  • 6
  • 0
#5 Ole Tange Blogger

Hvordan er det anderledes end at det offentlige gør brug af vores persondata uden at vi får noget at vide,

Det er et noget andet problem.

Cloud-leverandører vil gerne fremstå som om det er ligegyldigt om du kører din software på din server hjemme i virksomheden eller om du gør det i skyen.

Men ved at køre det i skyen, så giver du leverandøren mulighed for at tage en kopi af alt uden dit vidende. Det kan leverandøren ikke, hvis serveren står i virksomheden - og slet ikke hvis serveren ikke har adgang til internettet.

  • 8
  • 1
#6 Dave Pencroof

Det er et noget andet problem.

Nej. det drejer sig om at bruge følsomme persondata UDEN at spørge om lov, og at sende dem indenrigs og udenrigs, under mildt sagt elendige databehandler aftaler, noget som er bleve beskrevet bla her på siden selv efter GDPR ! Bare kik på denne V2 overskrift, https://www.version2.dk/artikel/lovaendring-skal-give-politiet-adgang-te...

Jeg har det relativt fint med Alphabet & co. De gør faktisk mere godt end skidt. De er ikke nær så "slemme" som mange "alm" borger mener. Fjæsbog er den uomtvisteligt helt stygge ulv. Heldigvis har USA og derfor fjæsbog just tabt til vores allesammens Max Schems og co IGEN !), desværre vil det sikkert ikke bedre noget i længden, idet politikerene sandsynligvis indgår lige så dårlige aftaler igen og igen

  • 3
  • 2
#7 Dave Pencroof

BTW. så er det FRIVILLIGT at bruge cloud løsninger, vil det ikke være værre at bruge amazon end google ? Industrispionage kan man ikke beskytte sig mod mm man selv håndere alle data, så hvis man vælger skyen, ja så beder man squ selv om det, det koster penge, og viden, at beskytte sit. De muligheder har du ikke med det offentlige !!

  • 0
  • 2
#8 Baldur Norddahl

Uden at kende detaljerne så virker det som om, at det netop er det, de har gjort. Så vidt jeg kan lure, så er RAM kryptering kun understøttet på nyere Ryzen processorer, så hvis du klikker checkboxen af, bliver din VM startet på en sådan processor.

Ja ok men jeg mente at de to angreb kan forhindres uden kryptering og uden performance tab. Eksempelvis implementere intel skylake et system der detektere rowhammer og automatisk laver en ram refresh på de omkringliggende rows, hvilket spolerer angrebet.

Jeg er sikker på at der stadig sælges tonsvis af sårbart hardware, men med tiden vil det forsvinde fra markedet, så at vi igen kan stole nogenlunde på vores ram. Jeg hævder ikke at der aldrig igen vil blive fundet fejl, men modsat eksempelvis Meltdown og Spectre, så er rowhammer noget der nemt kan stoppes nu hvor man er klar over problemet.

Rowhammer (og Rambleed) virker i øvrigt hellere ikke på gammel hardware. Det er primært DDR3 og DDR4 ram der er sårbart, så hvis du har noget der bruger ældre typer RAM er det ikke sårbart.

  • 0
  • 0
#9 Tobias Tobiasen

Men ved at køre det i skyen, så giver du leverandøren mulighed for at tage en kopi af alt uden dit vidende. Det kan leverandøren ikke, hvis serveren står i virksomheden - og slet ikke hvis serveren ikke har adgang til internettet.

Der har været eksempler hvor servere er blevet byttet ud under transporten med “bedre” servere der kunne snage inde i virksomheden. Bevares det er sikkert sjældent men egne servere er ingen garanti for at ingen uvedkommende kigger med.

  • 1
  • 0
#10 Sune Marcher

Ja ok men jeg mente at de to angreb kan forhindres uden kryptering og uden performance tab. Eksempelvis implementere intel skylake et system der detektere rowhammer og automatisk laver en ram refresh på de omkringliggende rows, hvilket spolerer angrebet.

Vores moderne CPU- og systemarkitekturer er så komplicerede, at der med ret høj sandsynlighed kommer nye angreb, der skal mitigeres... Så måske er det fint nok med hukommelseskryptering?

Det er vildt at vi er nået dertil, though. Man kan godt længes efter "This is the CPU of a Jedi Knight. Not as clumsy or random as a x86; an elegant CPU for a more civilized age".

Og ja ja, ARM bliver måske et reelt alternativ med det arbejde Apple har gang i, men er dén arkitektur ikke også efterhånden bloated ret godt?

  • 1
  • 0
#11 Jacob Gorm Hansen

Det ændrer ikke på, om Google kan tilgå dine data: De vil altid uden dit vidende kunne lave et snapshot af hele din virtuelle maskine – inkl CPU og dermed have adgang til alle dine data, og give dem videre til hvem de nu har en aftale med.

Det fremgaar ikke klart af pressemeddelsen, men hele ideen burde vaere at Google's hypervisor ikke kender til krypteringsnoeglen, og at et snapshot derfor er vaerdiloest. Noeglen er kun kendt for CPUen som generer den naar VM'en startes, ikke af Google's software.

Det er derfor at fx Live Migration ikke supporteres, omend det sagtens kan laves som Self-Migration inde fra VM'en, som jeg tidligere har demonstreret efter at Asger Jensen og jeg opfandt Live Migration tilbage i 2002.

Hvis det virker er det faktisk det gennembrud vi har ventet paa siden Cloud Computing kom paa banen, for det fjerner behovet for at stole paa sin cloud-provider, og goer det faktisk lettere for gud og hvermand at lave sin egen provider i konkurrence med fx Google.

Keywords som kan googles: secure enclaves, SGX, AMD SEV, TEE, Asylo.

mvh Jacob

  • 5
  • 0
#12 Ole Tange Blogger

Super spændende hvis Google ikke har adgang.

Men hvordan checker du det?

Med andre ord: Hvordan kan du vide, at din VM bliver spawnet på en CPU, hvor man ikke kan trække nøglen ud af, og at din VM ikke bare bliver spawnet på en CPU, hvor Google kan trække den information ud, og at de blot emulerer al funktionalitet, som får det til at se ud som om, din VM kører på en sikker CPU?

Bliver du i praksis ikke nødt til at stole på, at Google ikke lyver?

  • 6
  • 0
#13 Ole Tange Blogger

Og ja ja, ARM bliver måske et reelt alternativ med det arbejde Apple har gang i, men er dén arkitektur ikke også efterhånden bloated ret godt?

Kik lige på RISC V. Det er en ret imponerende medlemsliste (bl.a. Alibaba, Google, nVidia, Huawei).

RISC V er teknisk ikke et tigerspring i arkitektur som Mill, men der er dog ryddet gevaldigt op.

Jeg har svært ved at se, at RISC V ikke bliver den nye ISA til service chips - uanset om vi taler GPU'er, harddisk controllere, eller smartphones.

Hvis jeg skulle sætte penge på en efterfølger til x86, så er det ikke ARM, men RISC V. ARM får et kortvarigt boost som følge af Apple, men herefter tror jeg RISC V massivt tager over for alt, der ikke er high-performance og som ikke kræver x86 kompatiblilitet.

Som chip-producent må det være fedt ikke at skulle betale royalities til ARM, og som chip-køber må det være fedt at kunne skifte til en anden producent uden at ændre ens software.

  • 2
  • 0
#14 Poul-Henning Kamp Blogger

Hvis jeg skulle sætte penge på en efterfølger til x86, så er det ikke ARM, men RISC V. ARM får et kortvarigt boost som følge af Apple, men herefter tror jeg RISC V massivt tager over for alt, der ikke er high-performance og som ikke kræver x86 kompatiblilitet.

Mnjae, helt så enkelt bliver det nok ikke.

Det er nemt at kaste en processor sammen, en af de mindste på OpenCores.org er vist nok kun 80 linier VHDL.

Det der er svært er at lave maskerne til en chip der kører hurtigt.

Uanset hvor "RISC" dit instruktionssæt måtte være, bliver alting meget mere kompliceret når du skal pipeline dine instruktioner mens du venter på noget cache og RAM der er guddommeligt langsomt i forhold til din CPU clock.

Itanic, for alle dens fejl, var et forsøg på at vende processen: Lav hardwaren så hurtig som muligt og få så compilerne til at håndtere alle de underlige regler det medfører, f.eks at et par instruktioner efter et jump udføres inden jumpet faktisk gennemføres.

i386 kom aldrig op i clock-frekvens, det kunne simpelthen ikke lade sig gøre med det instruktionssæt.

amd64 instruktionerne blev designet til at kunne drives op i clock og det er blevet drevet op i clock, men det sidste årti er det sket på bekostning af det ene side-channel hul efter det andet.

ARM har haft forbandet svært ved at komme op i clock, grundlæggende fordi deres instruktionssæt er designet til at køre "memory-speed", dvs. lidt samme problem som i386 og derfor er det først med deres 64bit instruktioner de for alvor kan blive interessante.

Præcist hvor interessante ARM64 bliver, er stadig et åbent spørgsmål, formodentlig bliver det primært MIPS/FLOPS per Watt de kommer til at vinde på.

RISC-V er i ukendt land, det er godt nok smarte folk der har designet instruktionssættet, men en CPU der kørte 5-10 gange hurtigere end RAM var simpelthen ikke med i deres idégrundlag.

Hvis RISC-V bliver en stor success (I modsætning til: Får en masse omtale) bliver det formodentlig af storpolitiske årsager, ejerskabet af ARM holding er blevet meget politisk.

  • 3
  • 0
#18 Jens D Madsen

i386 kom aldrig op i clock-frekvens, det kunne simpelthen ikke lade sig gøre med det instruktionssæt.

Det kan diskuteres hvor meget indstruktionssættet betyder. Det som jeg syntes betyder noget, er processorens kompatibilitet med andre processorer.

Derfor, bør man når man laver en CPU tænke på, at en typisk applikation er en simulator til andre processorer. En simulator laves bedst ved at den oversætter - det vil sige, at man har et addressemap der svarer til den CPU vi emulerer, og et andet addressemap til den vi rigtigt kører på. Den emulerede processors addressemap vil normalt typisk indeholde jump instruktioner, hvor der hoppes til vores rigtige processors indstruktioner. Og der holdes styr på, når at der er selvmodificerende kode, stak mv. Det er en god øvelse, inden man begynder at udvikle CPU'er, at som minimum overveje, eller endog lave en compilerdrevet emulator, for at vide, hvilke problemer vi løber ind i. Så kan vi bedre overveje hvilke hardwarefeatures at vores CPU behøver. Det som er fordelen, ved en compilerdrevet emulator, er at vi ikke behøver at spekulere på indstruktionssæt. Vores CPU er kompatibel med alt. Vi oversætter ganske enkelt koden når den udføres første gang, og herefter gemmer vi den i cachen oversat, så den ikke oversættes igen.

Det, som er den oprindelige motivation for opgaven er egentligt supercomputere. Vi vil gerne kunne køre vores normale PC software en million gange hurtigere eller mere, på en stor super parallel computer. Dette er ikke et problem. Man simulerer den bare. Og programmet som emuleres bliver så splittet ud på millioner af askildte tråde, ved at den sekventielle maskinkode analyseres og paralleliseres. Løkker bliver analyseret, og delt op i flere, og eventuelt sendt til forskellige beregnere. Det er ganske enkelt umuligt, at lave en moderne CPU i hardware. Hardwaren vil fylde alt for meget, og have et for stort strømforbrug.

Ud over at tænke på, hvordan at man simulerer enhver CPU effektivt, og ikke mindst ved noget om hvordan man koder det, så er også vigtigt at vide, at computere aldrig har haft brug for ram lager - og at de er langt bedre uden. Og, at indbygge "kopimaskiner" i hardwaren, der holder styr på, at data kopieres. Da at programmerne og lageret kører direkte på harddisk, så betyder det også, at vi kan kopiere data hurtigt på harddisk, og i ramlager, og alle andre steder, da vores hardware kopimaskine fungerer med associationer. Har vores CPU f.eks. en REP MOV, så vil den automatisk køre på CPU'ens kopimaskine, og ikke tage nogen tid. Efter instruktionen, så associeres det kopierede område med det originale, uden det tager nogen tid. Og det gælder også harddisk, da ram og harddisk er det samme. Lige fra gamle dage eksisterede ram ikke - man brugte i stedet cache af harddisken, og åbne filer fik en addresse, som gav adgang til harddisken direkte gennem en cache. De kørte meget hurtigere end PC'er, fordi de kørte med RAM på harddisken.

  • 0
  • 2
Log ind eller Opret konto for at kommentere