Google toont minicomputer Vault voor versleutelen data

Google heeft vrijdagavond tijdens zijn I/O-conferentie een beveiligde minicomputer getoond waarmee data kan worden versleuteld en ontsleuteld. De computer, Project Vault, verkeert nog in experimentele fase, maar Google heeft voor ontwikkelaars vast een sdk uitgebracht.

Googles Advanced Technology and Projects-afdeling, kortweg ATAP, werkt momenteel aan het Vault-project. Dat omvat een minicomputer ter grootte van een micro-sd-kaart. Op de computer kunnen gebruikers tot 4GB aan belangrijke gegevens versleuteld opslaan.

Onder de motorkap beschikt Project Vault over een eigen arm-processor en een nfc-chip voor authenticatie. De computer draait op een real-time operating system, dat sterk is gericht op het beveiligen van gegevens. Zo levert het systeem software mee voor hashing, signing en batch-encryptie.

Project Vault kan met vrijwel alle apparaten die een micro-sd-kaartaansluiting hebben, communiceren. Die herkennen de computer namelijk als een regulier opslagstation. Dit betekent dat Vault ook platformonafhankelijk werkt en dus is te gebruiken in combinatie met bijvoorbeeld Android of Windows.

Vault is alleen meer dan een opslagstation. Het filesystem bestaat namelijk uit twee bestanden: een read- en een write-bestand. Dit betekent dat externe partijen in theorie nooit de communicatie daartussen kunnen inzien. Als voorbeeld liet Google chatsoftware zien die draaide op Vault. Daarbij werd de tekst versleuteld naar een ander Vault-apparaat verzonden en daarop ontcijferd.

Google maakte vrijdag niet bekend waar het de technologie uiteindelijk voor wil gebruiken en of Vault ook beschikbaar komt voor bestaande systemen. Wel zei de technologiegigant de minicomputer intern te testen, vermoedelijk voor zakelijk gebruik. Voor ontwikkelaars heeft Google de sdk via GitHub vrijgegeven onder de Apache-licentie. Die is, evenals de dev-board, volledig opensource tot aan de cpu-designs aan toe.

Reacties (29)

[SkyStreaker]

En natuurlijk wordt de source ook door een onafhankelijk platform (lees: instelling) gecertificeerd of moet ik toch ergens in de kleine letters een backdoor verstopt zien zitten?

[Reactie gewijzigd door SkyStreaker op 24 juli 2024 15:34]

[Armin]

De source vind ik niet zo erg belangrijk, aangezien het vooral om disk encryptie gaat. Veel belangrijker is dus of het encryptie formaat zoals op disk staat een geopenbaarde en goede standaard is. Immers uiteindelijk bescherm je die data, en zal het je een worst wezen wat de software doet. Een aanvaller zal namelijk zijn eigen software (kunnen) gebruiken en niet die van Google.

Vgl Bitlocker: closed source maar een 100% open standaard welke door iedereen te controleren is, en ook al vaak gecontroleerd is. Als de bits op de disk overeen komen met de standaard zit je goed, indien je de standaard vetrouwd. Igv Bitlockerr AES 128 CBC en SHA2-256. De vraag is dus wat men hier gebruikt betreft encryptie en balangrijker sleutel management.

[Dual Infinity]

Als de bits op de disk overeen komen met de standaard zit je goed

Nee.

Als je encryption key fijn naar de softwaremakers gestuurd wordt, is het exit security. Open source is een hele, hele belangrijke stap in de vertrouwensketen.

[Armin]

OK, als de key inderdaad opgestuurd wordt inderdaad, dat punt geef ik je.

Kernpunt echter was dat bij disk encryptie je in eerste instantie naar de standaard van de gebruikte disk encryptie plus key management kijkt. De werkelijke software die de bits naar disk schrijft is veel minder belangrijk want zal een aanvaller niet hoven gebruiken.

Open vs closed source is helaas soms een beetje een mode verschijnsel geworden waarbij men het threat model niet goed geanalyseerd heeft. Close dource kan juist bij disk encryptie net zo goed zijn, waar open source uiteindelijk net zo goed op vetrouwen gebaseerd is in de praktijk.

[Dual Infinity]

Close dource kan juist bij disk encryptie net zo goed zijn, waar open source uiteindelijk net zo goed op vetrouwen gebaseerd is in de praktijk.

Weer nee.

Ja, je hebt gelijk dat de encryptiemethode in specifieke instanties extern te controleren is. Maar in de code kan prima staan dat er op de 1e van elke maand een andere zwakke methode gebruikt wordt (om maar wat te noemen). Je voorgestelde verificatie van wat feitelijk een black box is, is dan ook niet 100% betrouwbaar.

Natuurlijk is open source software geen magische oplossing. De code moet alsnog geaudit worden en er zijn nog tig andere zwaktes in de keten, maar om te zeggen dat het dus 'allemaal vertrouwen is' en closed source daarom niet minder veilig is dan open source is een onjuiste en gevaarlijke gedachte.

[bwerg]

Als de bits op de disk overeen komen met de standaard zit je goed, indien je de standaard vetrouwd.

Los van wat Dual Infinity aangeeft vergeet je dan ook side-channel attacks. Al is dat ook zonder source te controleren maar 'de bits zijn goed, dus klaar' is een beetje kort door de bocht.

[Armin]

Klopt uiteraard en ik ging ook wat kort door de bocht, maar juist bij disk encryptie zijn de side channels zoals je zelf ook al aangeeft goed te controleren zonder source omdat ze doorgaans goed gedefinieerd zijn indien je key management en encryptie standaarden weet.

Mijn eerste reactie bij het lezen van dit artikel was dan ook niet "Oh, is het open source", maar "Oh wat voor standaard gebruikt men". Dat is namelijk vrijwel altijd veel relevanter voor de security van data encryptie. Open source wordt helaas teveel een mode verschijnsel met binaire goed/fout waarden, terwijl het uiteindelijk enkel een hulpmiddel is om vetrouwen te krijgen.

In deze context zie ik inderdaad vooral waarde van open source bij het vinden van implementatie fouten in de software, zoals niet wissen van data na decryptie uit geheugen (al zal het waarschijnlijk een hardware buffer gebruiken) of slechte random generator voor key generatie. Beide zijn soms makkelijker te zien door de source te bekijken, al ook zonder source te controleren.

Maar de meeste reageerders beginnen weer over backdoors etc. Bugs en fouten zijn veel grotere bronnen van problemen in de praktijk. En daarna komen eerder foute standaarden etc. En die standaarden geven ook aan in welke hoek je naar bugs moet zoeken.

[David Mulder]

Voor bedrijven als Google is het juist waardevol als het internet veilig en gesloten is. Waarom? Omdat dat betekend dat meer mensen hun diensten die afhankelijk zijn van het internet zullen gebruiken. Dus nee, ik zou er niet bepaald snel een backdoor in verwachten, want in dat geval zouden ze zichzelf uit de markt zetten.

[Verwijderd]

Als het een RTOS* systeem is, kan dit dan nog wel geüpdatet worden? Want er is altijd wel een of andere security white hacker die na een paar maanden een blogje schrijft over de omzeiling/exploitatie ervan. Het niet kunnen patchen maakt het dan vrij nutteloos.
Daarnaast een mooi initiatief, wat de NSA zeker niet gaat leuk vinden (en eventueel ook Rusland en China).
(*): RTOS=Real Time Operating System

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:34]

[Mr_gadget]

Wel vreemd dat het een RTOS is.. Het hoeft geen auto te besturen oid, RTOS'en worden vaak voor machinebesturingen gebruikt. Alleen versleutelen en ontsleutelen met een redelijke snelheid. Maar je hoeft geen deterministisch gedrag tot in de milliseconden.

Ik neem aan dat het wel geupdate kan worden. Maar dan in een extern apparaat oid. Je wil ook niet dat de NSA via een app een update naar de Vault doorstuurd.

[Reactie gewijzigd door Mr_gadget op 24 juli 2024 15:34]

[John Doos]

Hmmm...

Ben ik de enige die het merkwaardig vind dat Google en Privé in 1 zin gaan

[bbob]

Zal er vanaf hangen of de software open source is zodat er op achterdeurtjes gezocht kan worden.
Is de software closed source is deze per definitie niet te controleren en dus niet te vertrouwen.

[koelpasta]

lol., dit is closed hardware. Ook al heb je alle sources weet je nog niet wat er werkelijk in zit.

[Armin]

En als de software open is, moet je nog steeds vertrouwen dat:

- de gecompileerde code ook van de open source is
- de open source geen backdoors/bugs bevat
- de mensen die beweren dat dat laatst zo is, te vertrouwen zijn
- die mensen het niet gemist hebben

Uiteindelijk is het een kwestie van vertrouwen. Het open zijn van de source kan daar een rol in spelen, maar tevaak wordt de suggestie gedaan dat het een noodzakelijke factor is, laat staan een daarna gegarandeerde beslissende factor.

Vertrouwen is uiteindelijk per definitie een persoonlijk iets.

[bbob]

Vergis ik me niet dat er laatst ook onderzocht is op backdoors in open source encryptie software en niets gevonden is.

Nu kun je natuurlijk ook stellen, zijn die onderzoekers te vertrouwen.
Gemist hebben kan altijd, dat blijkt wel uit bugs de laatste tijd ook in linux software.
100% bugvrij is er ook niet.

Toch kan open source een betere garantie bieden dan closed source.
Zelf compilen kan natuurlijk ook als je er verstand van hebt

[Iblies]

TOR-netwerk is ook 'uitgevonden' tbv Amerikaanse inlichtingen en die veilig te stellen.
Op een gegeven moment is dat ook gekaapt door allerlei twijfelachtige clubjes.

De techniek die hier gebruikt wordt lijkt me niet erg ingewikkeld,
zou me dus niet verbazen als google op korte-midden termijn zijn handen hier vanaf haalt. De risico's die hier aan verbonden zijn, lijken me groter dan Corp.

[eheijnen]

TOR-netwerk is ook 'uitgevonden' tbv Amerikaanse inlichtingen en die veilig te stellen.
Op een gegeven moment is dat ook gekaapt door allerlei twijfelachtige clubjes.

Zo is het ook met het breekijzer gegaan...

[Verwijderd]

In tegenstelling tot wat vaak wordt gedacht is Google niet geïnteresseerd in jouw privé gegevens, anders dan dat een robotje in jou 'instance' bijhoudt wat je interesses zijn en deze als metadata presenteert aan een advertentie robot in een beveiligde omgeving.

In feite niks anders dan de bakker die weet hoeveel krentebollen jij altijd besteld. Behalve dan dat de bakker een persoon is en aan de hand van die gegevens kan roddelen over een vermoeden dat jij een affaire hebt oid.

Google wíl niet eens als bedrijf bij die gegevens kunnen omdat dat het bestaansrecht van het bedrijf in gevaar kan brengen. Dat de NSA daar anders over denkt en wederrechtelijke middelen gebruikt om bij dit profiel te kunnen kan Google niet worden aangerekend. Google heeft ook zeer vaak deze handelswijze aangevochten en de encryptie tussen datastromen vaak verbeterd.

Dit itt tot andere bedrijven die op eigen initiatief naar de NSA zijn gegaan met het aanbod gegevens door te geven.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:34]

[jcvw]

Toch mooi om te zien hoe terminologie verandert door de loop der tijd: "Google toont minicomputer Vault voor versleutelen data". En als je dan op Wikipedia kijkt: http://nl.wikipedia.org/wiki/Minicomputer :
Apparaten ter grootte van een koelkast, terwijl we het hier over een microSD-formaat computer hebben... Op wikipedia staat zelfs: "Tegenwoordig is de term 'minicomputer' niet echt gangbaar meer, de grens tussen krachtige pc, workstation en server is vervaagd. De term zou nog gebruikt kunnen worden voor alle computers die qua prestatie en functie tussen de personal computer en mainframe of supercomputer in liggen, en die niet op pc- of Apple Macintosh-architectuur gebaseerd zijn."

[t1mmy]

Als ik 1 bedrijf niet vertrouw met mijn versleutelde data dan is het Google wel, laat staan dat ik mijn data door google laat versleutelen

[SCS2]

Ik snap het niet, wat is het nut van een zelf encryptende kaart?
Dus de data is encrypted. Waar waar komt de sleutel vandaan?

Is dat ding een soort truecrypt container, en moet de user met een stuk software inloggen?
Dus geeft de user de sleutel op, bijv. op de telefoon of zo. Dan is er dus communicatie met dit ding waar de sleutel instaat.

Of is het net als de encrypted ssd's: er is een vaste eenmalige sleutel, zodat de data onleesbaar op de chips staat.
Maar dan is die data toch gewoon vrij beschikbaar als de kaart "normaal" benadert wordt?

[gladius1983]

Dan wordt het tijd dat de volgende nexus generaties een microsd slot krijgen. Google heeft nu een reden uit eigen stal.

[Dorank]

Dat was precies mijn gedachte. Het is nog maar een kleine stap om de sdcard te voorzien van een filesystem dat rechten snapt (het vervangen van usbstorage door mtp zorgt ervoor dat je geen directe toegang meer hebt van een desktop die eventueel dat fs niet snapt (dus geen $FAT meer nodig)) en eventueel wat extra permissies om applicaties toegang te laten krijgen tot elkaars data (indien de applicatie die daadwerkelijk eigenaar is, dat toestaat).

[Verwijderd]

Het filesystem bestaat namelijk uit twee bestanden: een read- en een write-bestand. Dit betekent dat externe partijen in theorie nooit de communicatie daartussen kunnen inzien.

Gezien dit artikel de boel weer eens in plebianentaal uitlegt, kan iemand mij uitleggen waarom dit precies is? Hoe gaat dit in zijn werk, waarom zouden externe partijen nooit 'communicatie daartussen' kunnen inzien?

[matjojo]

omdat (denk ik, ik ben geen expert) de comminucatie daartussen verloopt op de chip zelf(hij heeft zelf een processor) en niet met dataverbindingen in het medium waar de "vault" in zit.

[flyspy_nl]

Wat ze waarschijnlijk doen is dat je een tekst file schrijft naar de Sd kaart in het mapje Write.
En in het mapje read vind je dan de file terug die ge-encrypt is. Zo kan je makkelijk files encrypten.

[Verwijderd]

Ik begrijp het ook niet maar vermoed het volgende:

Password cq encryptiesleutel gaat via NFC
Wil je data encrypten dan sla je op in de WFILE map
Wil je data decrypten dan lees je in de RFILE map
De processor in de micro SD card voert de encryptie uit.

[eheijnen]

Even afwachten om te kijken hoe lang het duurt voor dat dit gekraakt wordt...

[beerse]

binnen Tweakers 2 google projecten na elkaar: Vault en Ara. 1 met een module voor encrypty, de ander een modulair mobieltje. Maar in beide berichten geen koppeling. Heb ik iets gemist, is het een gemiste kans of heb ik nu iets nieuws verzonnen?

Maak binnen vault een module die in de ara omgeving kan worden opgenomen om de encryptie te kunnen verzorgen.