Swift krijgt module voor homomorfe encryptie voor analyses op versleutelde data

Apple voegt een module voor homomorfe encryptie toe aan programmeertaal Swift. Daarmee kunnen berekeningen en analyses worden uitgevoerd op versleutelde data zonder die eerst te hoeven ontsleutelen. Met de module kunnen ontwikkelaars de functie aan een app toevoegen.

Apple biedt de nieuwe package aan als opensourcemodule voor programmeertaal Swift. Het bedrijf heeft de broncode ervan op GitHub gezet. Met die module kunnen Swift-ontwikkelaars homomorfe encryptie toevoegen aan apps of andere software. Homomorfe encryptie is een manier om bepaalde analyses te doen op versleutelde data. Dat is handig voor bijvoorbeeld clouddiensten die data versleuteld willen opslaan, maar er toch bepaalde handelingen op willen uitvoeren.

Grote diensten zoals Microsoft gebruiken zo'n proces bijvoorbeeld in de Password Monitor in Edge, zodat wachtwoorden versleuteld kunnen blijven, maar Microsoft toch kan analyseren of ze in eerdere datalekken zijn voorgekomen. Apple zegt homomorfe encryptie, of HE, ook te gebruiken bij het live opzoeken van informatie over binnenkomende telefoonoproepen. Tweakers schreef in 2021 een achtergrondartikel over homomorfe encryptie.

Die functie komt nu ook in Swift te zitten. De implementatie is beschikbaar als een Swift Package Manager-package. Ook kunnen ontwikkelaars de package via Xcode inladen. Apple gebruikt het Brakerski-Fan-Vercauteren-stelsel, dat iets trager is dan andere HE-stelsels, maar wel accuratere informatie weergeeft. Volgens Apple is dat veiliger doordat het op Ring learning with errors is gebaseerd, waarmee de methode bestand is tegen postquantumcryptografische aanvallen.

Reacties (23)

[CAPSLOCK2000]

Dit is een van de belangrijkste ontwikkelingen op het gebeid van privacy en security sinds de uitvinding van encryptie. Het is een oplossing voor een hoop conflicten tussen de juridische en technische werkelijkheid.

Kort gezegd willen we allemaal gebruik maken van goedkope leveranciers zoals de Amerikaanse clouddiensten. Maar iedere keer dat je data door iemand anders wil laten verwerken is dat een risico op een lek. De andere partij kan immers bij je data. Uiteraard spreek je af dat het niet bedoeling is, maar technisch blijft het mogelijk. Internationaal data delen is juridisch gezien nog lastiger en aangezien zoveel IT uit de VS of China komt is dat voor Europeanen beste vervelend.

Deze techniek lost dat voor een deel op. Nu kun je wel data door iemand anders laten verwerken met de technische zekerheid dat die ander je data niet direct kan inzien en dus ook niet kan laten lekken.
Juridische afspraken zijn mooi, maar technische zekerheid is beter.

[Minimise]

Maar hoeveel wil jij wel extra betalen voor extra trage berekeningen? Cloud is al duur , en met zware homomorfe encryptie het veelvoud van duur? Wat als de sleutel uitlekt?

[Reactie gewijzigd door Minimise op 31 juli 2024 14:53]

[CAPSLOCK2000]

Maar hoeveel wil jij wel extra betalen voor extra trage berekeningen? Cloud is al duur , en met zware homomorfe encryptie het veelvoud van duur? Wat als de sleutel uitlekt?

Dat ligt er aan hoeveel het me kost als het fout gaat.
Iedere (security)maatregel is een balans tussen risico's en kosten.

[Frame164]

Hoeveel wil jij extra betalen voor een beter slot op je voor- en achterdeur of op extra veiligheidbeslag bij je kozijnen? Dat is precies dezelfde vraag. Voor een schuurtje waar slechts wat spullen liggen opgeslagen ga je niet zo;n veilig slot op zetten als die je voor je voordeur zal gebruiken. Voor digitale beveiliging maak je dezelfde overwegingen.

[Minimise]

Zeg jij het maar. Zelfs mensen vanuit de medische hoek en fintech hoek kwamen niet helemaal uit op deze vraag…

[nst6ldr]

In dat geval kunnen we beter alles plain-text opslaan, encryption-at-rest kost ook alleen maar cycles en ook die keys kunnen uitlekken.

Wát een suffe dooddoener dit.

[Minimise]

AES zit ingebakken in de hardware accelerator, homomorfe encryptie niet! AES heeft standaard sleutel beheer met Secure Enclaves, homomorfe encryptie is vaak veel beperkter. AES is veel beter bestudeerd tegen zwakheden, homomorfe encryptie veel minder!

[Reactie gewijzigd door Minimise op 31 juli 2024 14:58]

[The Zep Man]

AES heeft standaard sleutel beheer met Secure Enclaves,

AES is enkel een algoritme dat voor symmetrische versleuteling zorgt. Het gebruik van AES zegt niets over sleutelbeheer.

Waar een vraag is zal een aanbod zijn. Zo ook voor cryptoanalyse en hardwareacceleratie van nieuwe primitieven.

[Reactie gewijzigd door The Zep Man op 31 juli 2024 15:06]

[Minimise]

Het is een verwijzing naar wat de grote massa gebruikt zoals SGX op de meeste cloud servers.

[nst6ldr]

AES is een standaard, dat heeft niks met secure enclaves te maken, de sleutelbeheer hangt af van de wijze waarop men deze implementeert. De zes instructies waar je naar verwijst zijn slechts passes zonder enige cryptografisch model.

[nst6ldr]

AES is symmetrische versleuteling, homomorfe versleuteling valt in een compleet andere categorie. Geen ChatGPT voor nodig. Ik ga ook niet vragen aan ChatGPT waarom een auto in een parkeergarage kan staan maar een spoorweg niet.

Dus wederom: een enorm flauwe dooddoener om een weinig tastbare kostenpost te hangen aan een module waar we als samenleving enorme voordelen bij hebben.

[lenwar]

Secure Enclaves gebruiken over het algemeen (op het moment zelfs altijd?) AES. Maar dat had net zo goed een andere versleutelingsalgoritme kunnen zijn.
AES is een subset van Rijndal (het wordt in de praktijk gezien als de opvolger van DES).

Homomorfe versleuteling heeft niets met het gebruikte algoritme te maken. Het is deels gebaseerd op wiskundige groepentheorie.

[Minimise]

Rijndael AES is niet voor niets een #1 standaard, want niemand die net zoveel geld in de #2 TwoFish AES finalist gaat gooien. Homomorfe heeft heel veel te maken met het gebruikte algoritme, maar een heel beperkte wiskundige groep kan homomorfe zijn! RSA is bijvoorbeeld maar slechts gedeeltelijk homomorfe en het in het artikel vermelde RLWE is volledig homomorfe en zelfs post-quantum!

[Reactie gewijzigd door Minimise op 31 juli 2024 17:53]

[n4m3l355]

Daar ga je vanuit dat juridische uitspraken een compleet beeld geven. Apple heeft er echter een handje naar om uitspraken te doen die mooi klinken maar de realiteit is vaak behoorlijk anders. Juridisch mag het dan allemaal wel correct zijn maar intend kan heel anders zijn. Dit maakt mij dan ook eerder wantrouwend, waar Apple al eerder met een bijzondere aanpak kwam tegen CP (geef apple al je persoonlijke data maar), klinkt dit technisch beter maar is dit in de uitvoer ook zo?

Voor mij zou privacy voor alles moeten komen ongeacht wat de gebruiker doet. Ik geef de politie uiteindelijk ook niet een extra sleuteltje tot mijn huis want ik doe toch niks raars.

[CAPSLOCK2000]

Daar ga je vanuit dat juridische uitspraken een compleet beeld geven. Apple heeft er echter een handje naar om uitspraken te doen die mooi klinken maar de realiteit is vaak behoorlijk anders.

Wiskunde is wiskunde, daar kan geen Apple jurist wat aan veranderen. Het mooie van deze techniek is, dat mits goed geimplementeerd, Apple er niet om heen kan. Apple heeft geen sleutel, die heb je zelf in eigen beheer.
Natuurlijk kan Apple als beheerder van het OS op laag niveau gekke dingen doen* maar zolang je kan controleren dat je alleen maar versleutelde bitjes naar buiten stuurt weet je zeker dat Apple er niks mee kan.

it maakt mij dan ook eerder wantrouwend, waar Apple al eerder met een bijzondere aanpak kwam tegen CP (geef apple al je persoonlijke data maar), klinkt dit technisch beter maar is dit in de uitvoer ook zo?

Voor mij zou privacy voor alles moeten komen ongeacht wat de gebruiker doet. Ik geef de politie uiteindelijk ook niet een extra sleuteltje tot mijn huis want ik doe toch niks raars.

De techniek is vergelijkbaar maar het verschil is dat het CP systeem van Apple er van uit gaat dat Apple (mede)eigenaar van de sleutel is. Ik kan niet uitsluiten dat ze in dit nieuwe systeem een achterdeur hebben of zichzelf een sleutel geven maar daar ga ik niet van uit. Je gaat niet zo'n systeem opzetten als dat je bedoeling is, dan had je beter niks kunnen doen en alles bij het oude laten.

* Fundamenteel vind ik het geen goed idee om OS, applicaties en/of hardware door dezelfde partij te laat maken. Ik heb liever dat ze allemaal wantrouwig naar elkaar toe zijn dan dat ik een grote IT-god moet vertrouwen om de hele stack in de gaten te houden. Machthebbers zichzelf laten controleren gaat vroeg of laat altijd fout. Misschien moet ik eens een Trias Politica voor IT Security & Beheer opstellen.

[Quacko]

Een vergevorderde use case hiervan waar IBM pionierswerk rond heeft gedaan https://research.ibm.com/...ng-homomorphic-encryption.
We gaan ook AI modellering kunnen laten doen zonder dat de data gekend moet zijn bij de modelleerder.
Ik hoop echt dat we in de toekomst zoveel mogelijk hiernaar kunnen overstappen zodat onze data privé blijft maar we toch slimme Tooling en AI en meer kunnen blijven gebruiken.

[Reactie gewijzigd door Quacko op 31 juli 2024 20:53]

[T-men]

[...] bijvoorbeeld in de Password Monitor in Edge, zodat wachtwoorden versleuteld kunnen blijven, maar Microsoft toch kan analyseren of ze in eerdere datalekken zijn voorgekomen.

Dus... met die tool kan Microsoft kijken of mijn password is gelekt. Dat klinkt mooi. Maar hoe werkt dat dan ?

Stel: in een lek is het wachtwoord 'Welkom01' van mij gevonden. (maak je geen zorgen... het is maar een voorbeeld )
Microsoft gaat analyseren en ontdekt dat ik dat wachtwoord ook op Tweakers.net heb gebruikt. Dan weten ze impliciet toch ook meteen dat 'Welkom01' ook op Tweakers.net mijn wachtwoord is ?

Dat lijk me niet de bedoeling. Maar daarom denk ik ook dat dat niet is hoe het werkt. Maar hoe dan wel ?

[Alfredo]

De decryptie van de resultaten gebeurt door de client (je browser), niet door Microsoft zelf. Zij leren dus niet of je wachtwoord reeds in hun database voorkomt.
Ik vind een gerelateerde techniek iets eenvoudiger te begrijpen (of voor mij om het uit te leggen). Google doet hetzelfde met hun wachtwoordmanager, maar gebruikt Private Set Intersection (PSI) via secure multiparty computation (MPC) in plaats van Homomorphic Encryption (HE). Het idee is dat bepaalde cryptographische constructies commutatief zijn. Dat wilt zeggen dat A*B gelijk is aan B*A. Hoe gebruik je dat idee om aan Google te vragen of je wachtwoord gelekt is, zonder je wachtwoord aan Google te geven?

Jij hebt je wachtwoord X en versleutelt dat met sleutel A. A is enkel gekend door jezelf. Je stuurt X*A door naar Google. Zij kennen A niet en kunnen X dus ook niet achterhalen. Google heeft een lijst met gelekte wachtwoorden en versleutelt die allen met sleutel B. Ze versleutelen ook jouw data met B, dus nu heb je X*A*B, en Y*B, Z*B, ... Ze sturen jou beide terug door. Jij kent B niet dus je weet niet welke wachtwoorden Google nog in hun database heeft. Maar je kent A, dus nu kan je X*A*B/A uitvoeren (of correcter, vermenigvuldigen met de inverse van A omdat de berekeningen op een elliptische curve over een finite field of galoisveld gebeuren), en je krijgt nu X*B. Ofwel, jouw wachtwoord enkel versleuteld met de sleutel van Google. En omdat Google je de lijst van hun wachtwoorden versleuteld met B ook heeft doorsgestuurd, kan je kijken of jouw X*B voorkomt in de lijst van Y*B, Z*B, ... En zo leer je of je wachtwoord gelekt is, zonder dat Google dat ook te weten komt.
In de praktijk is de lijst van wachtwoorden aan de kant van Google erg groot en willen ze geen lijst met miljarden vermeldingen doorsturen. Dus als optimalisatie hash je je wachtwoord eerst en stuur je de eerste paar bits van die hash door naar Google. Die gebruiken ze om je een subset van hun database door te sturen: enkel die met dezelfde eerste bits. Dus je krijgt 10,000 versleutelde wachtwoorden terug ipv miljarden. Dat lekt uiteraard iets van informatie. Google kan nu 1/10000 gokken wat je wachtwoord is, maar die trade-off vinden ze aanvaardbaar.

[CAPSLOCK2000]

Microsoft gaat analyseren en ontdekt dat ik dat wachtwoord ook op Tweakers.net heb gebruikt. Dan weten ze impliciet toch ook meteen dat 'Welkom01' ook op Tweakers.net mijn wachtwoord is ?

Dat is moeilijk uit te leggen zonder ingewikkelde wiskunde. Hieronder een vergelijking om je een beetje gevoel te geven hoe het werkt, technisch gezien klopt het echter niet.

Denk aan een corona-test. Die test doe je normaal thuis met zo'n testkit en is voor 1 persoon.
Toen er te weinig tests waren heeft iemand bedacht om speeksel van 10 mensen tegelijk op 1 testkit te smeren. Maar als niemand in de groep besmet is blijft de test negatief en heb je maar 1 test nodig voor de hele groep van 10 mensen.
Als iemand uit die groep corona heeft gaat de test af en moet je ze allemaal los testen.

Dat laatste lijkt een beetje op hoe deze techniek werkt. Je weet dat iemand in groep besmet is, maar je weet niet wie.

Nu ga je nog een stap verder. Je maakt namelijk je eigen corona testkit. Het verschil is dat je geheim houdt hoe je die test moet aflezen. Alleen jij weet welke streepjes zeggen of iemand besmet is of niet.
Nu kun je de test door iemand anders laten doen. Die ziet wel streepjes verschijnen maar heeft geen idee wat die streepjes betekenen.
Die tester geef je niet direct buisjes met speeksel, maar je maakt zelf verschillende speekselmengsels.
Door verschillende speekselmengsels te maken en te testen kun je afleiden wie er besmet is en wie niet.

De partij die test weet niet van welke mensen dat speekselmengsel afkomstig is én weet niet wat de uitslag van de test is.

[Cafe Del Mar]

Klinkt als een oplossing voor Schrödingers kat: in de doos kijken en toch ook niet?

[ultimasnake]

Misschien dan eerder een doos met een kat erin maar voorzien van een 1% licht doorlatend materiaal waardoor je nog net kan opmaken dat er iets in leeft? Schrödingers partially see through paradox

[mutley69]

Dit lijkt me iets creepy - security by obscurity?