Crypto applications at rest.pdf

# Status van encryptie en beveiligingsuitdagingen Dit onderwerp verkent de huidige stand van encryptietechnologieën, belicht de opgeloste uitdagingen op het gebied van veilige communicatie, en identificeert de resterende complexe problemen met betrekking tot veilige dataopslag en berekeningen op versleutelde data. ### 1.1 Huidige status van encryptie De huidige status van encryptie kan worden onderverdeeld in verschillende domeinen: communicatie (in transit), opslag (at rest), en gebruik (tijdens berekeningen). #### 1.1.1 Veilige communicatie (in transit) Veilige communicatie is grotendeels een opgelost probleem. Historische mijlpalen omvatten [2](#page=2): * 1977: DES [2](#page=2). * 1989: GSM [2](#page=2). * 1998: IPSEC [2](#page=2). * 2000: AES, KASUMI, SHA-2 [2](#page=2). * 2005: ECDSA, ECDH [2](#page=2). * 2005: AES-GCM [3](#page=3). * 2007: XTS-AES [3](#page=3). * 2008: ChaCha20, Poly1305 [3](#page=3). * 2018: TLS 1.3 [3](#page=3). Hoewel de technologie voor veilige communicatie bestaat, wordt deze vaak niet primair gebruikt om individuen te beschermen, maar om de belangen van organisaties te waarborgen, zoals banken en bedrijven. Metadata, zelfs bij versleutelde communicatie zoals WhatsApp, kan nog steeds commercieel worden geëxploiteerd. Veilig communiceren via telefoongesprekken, inclusief 5G, is nog steeds niet volledig opgelost [3](#page=3). #### 1.1.2 Veilige opslag (at rest) Veilige opslag van data wordt beschouwd als een opgelost probleem, met methoden zoals XTS-AES. Dit omvat de encryptie van data die is opgeslagen op apparaten of servers [3](#page=3). #### 1.1.3 Berekeningen op versleutelde data (tijdens gebruik) Dit is het meest uitdagende domein en is nog niet volledig opgelost. Bestaande oplossingen voor berekeningen op versleutelde data, zoals Secure Multiparty Computation (SMC), Homomorphic Encryption (HE), Federated Learning en Functional Encryption, brengen aanzienlijke overhead met zich mee op het gebied van rekenkracht of communicatie. Hoewel het voor alle data niet haalbaar is, kan het voor zeer gevoelige data momenteel wel worden toegepast [2](#page=2) [3](#page=3). ### 1.2 Encryptie-algoritmen en hybride benaderingen #### 1.2.1 Symmetrische versus asymmetrische encryptie Symmetrische encryptie is aanzienlijk sneller, tot wel duizend keer, dan asymmetrische encryptie. In de praktijk worden beide gecombineerd: een willekeurige sleutel wordt gegenereerd voor symmetrische encryptie (bijvoorbeeld AES), en deze sleutel wordt vervolgens versleuteld met asymmetrische encryptie (bijvoorbeeld RSA) om te worden verzonden [4](#page=4). #### 1.2.2 Details van algoritmen * **DES (Data Encryption Standard):** Een ouder symmetrisch algoritme met blokken van 64 bits en een 56-bits sleutel [4](#page=4). * **AES (Advanced Encryption Standard):** Werkt met blokken van 128 bits. * AES-128 gebruikt een 128-bits sleutel [4](#page=4). * AES-256 werkt ook met blokken van 128 bits, maar gebruikt een 256-bits sleutel [4](#page=4). * **RSA:** Een populaire asymmetrische algoritme met gangbare sleutellengtes van 2048 of 4096 bits [4](#page=4). * **ECC (Elliptic Curve Cryptography):** Een ander asymmetrisch algoritme, typisch met sleutellengtes van 256 of 512 bits, maar voornamelijk gebruikt voor digitale handtekeningen in plaats van encryptie [4](#page=4). #### 1.2.3 Hybride benadering De combinatie van symmetrische en asymmetrische encryptie is een standaardpraktijk. De symmetrische sleutel (K) wordt gebruikt voor de snelle encryptie van de bulkdata, terwijl asymmetrische encryptie wordt gebruikt om deze sleutel veilig te verzenden [4](#page=4). #### 1.2.4 Sleutelbeheer en herstel Organisaties accepteren het risico niet dat het verlies van een persoon of sleutel leidt tot onbeschikbaarheid van data. Daarom wordt data vaak dubbel versleuteld [4](#page=4): 1. Voor de beoogde ontvanger. 2. Voor een sleutelherstelagent (wiens privésleutel zeer goed beveiligd is) voor noodgevallen [4](#page=4). Organisaties kunnen ook procedures implementeren, soms gecombineerd met technologie, waarbij twee personen vereist zijn voor autorisatie van sleutelherstel [4](#page=4). ### 1.3 Beveiligingsuitdagingen in specifieke domeinen #### 1.3.1 Cloudopslag Cloudopslag presenteert twee primaire encryptiebenaderingen: server-side en client-side encryptie. ##### 1.3.1.1 Server-side encryptie Bij server-side encryptie worden de sleutels en de encryptie-/decryptieoperaties op de server uitgevoerd [5](#page=5). * **Voordelen:** Systeembeheerders kunnen de versleutelde bestanden niet lezen; centrale encryptie/decryptie en sleutelbeheer; mogelijkheid tot geavanceerde authenticatie zoals multi-factor authenticatie [5](#page=5). * **Nadelen:** Vertrouwen in de servercode is vereist (kan meer doen dan verwacht); communicatie tussen desktop en cloud is niet versleuteld (hoewel TLS kan worden gebruikt); gesynchroniseerde kopieën en caches op de desktop zijn onversleuteld; wetshandhavers kunnen cloudproviders dwingen tot het installeren van surveillance software [5](#page=5) [6](#page=6). * **Voorbeelden:** Owncloud, Nextcloud [6](#page=6). ##### 1.3.1.2 Client-side encryptie Bij client-side encryptie worden alle encryptie- en decryptieoperaties op de client uitgevoerd; de cloud ontvangt alleen versleutelde data [7](#page=7). * **Voordelen:** Niemand op de server, inclusief de code, kan de data in de cloud lezen; metadata kan volledig onbekend blijven aan de cloud indien gecombineerd met chunking [7](#page=7). * **Nadelen:** Sleutelopslag op het eindpunt, dat het zwakste punt is; data moet worden ontsleuteld voor gebruik, wat kan leiden tot onversleutelde data op de client; onmogelijk in multi-user omgevingen voor delen van data; deduplicatie is moeilijk of onmogelijk; wachtwoordherstel kan lastig zijn; vertrouwen in de client-software ontwikkelaar blijft noodzakelijk; browser plugins of JavaScript updates gebeuren zonder kennis van de gebruiker; metadata kan nog steeds zichtbaar zijn tenzij chunking wordt gebruikt [7](#page=7). * **Voorbeelden:** Cryptomator, Seafile, Spideroak, SparkleShare. Veracrypt (voorheen Truecrypt) is een container voor de persoonlijke desktop en geen cloudoplossing [8](#page=8). #### 1.3.2 Cryptomator Cryptomator biedt client-side encryptie waarbij metadata op de server grotendeels verborgen blijft [9](#page=9). * **Sleutelafleiding:** Gebruikt `scrypt` voor wachtwoord-gebaseerde sleutelafleiding [9](#page=9). * **Key Wrap:** Gebruikt de Key Wrap-modus van AES om de encryptiesleutel en MAC-sleutel af te leiden, wat authenticatie garandeert [9](#page=9). * **Masterkeys:** De KEK (Key Encryption Key) wordt afgeleid via `scrypt`, en masterkeys worden versleuteld met AES Key Wrap. De gewrapte sleutels en afleidingsparameters worden opgeslagen in een JSON-bestand [9](#page=9). * **Gebruikerssleutelparen:** Bij de eerste login genereert elke gebruiker een nieuw EC-sleutelpaar. De privésleutel wordt versleuteld met de Account Key en de Device Key van elk apparaat [9](#page=9). * **Bestandsencryptie:** Bestanden worden opgesplitst in chunks en versleuteld met AES-GCM. Vroegere versies gebruikten AES-CTR met HMAC [10](#page=10). * **Bestandsnamen:** De cleartext bestandsnaam wordt versleuteld met AES-SIV. Als de versleutelde naam te lang is, wordt een kortere SHA-1 hash-gebaseerde naam gebruikt [10](#page=10). * **Audit opmerking:** Een audit in 2017 wees uit dat de standaard AES-modus in de gebruikte bibliotheek AES/ECB was [10](#page=10). #### 1.3.3 Google encryption at rest Google implementeert meerdere lagen van encryptie voor data in productie-datacenters [11](#page=11). * **Chunking:** Data wordt opgesplitst in chunks (tot enkele gigabytes) [11](#page=11). * **Individuele Data Encryption Keys (DEKs):** Elke chunk wordt versleuteld met een unieke DEK, zelfs als ze van dezelfde klant zijn of op dezelfde machine staan. Updates van data gebruiken nieuwe sleutels [11](#page=11). * **Opslag:** Chunks worden verspreid en gerepliceerd voor back-up en disaster recovery. Een aanvaller zou zowel de chunks als de bijbehorende sleutels nodig hebben [11](#page=11). * **AES-256:** DEKs gebruiken standaard AES-256 [11](#page=11). * **Key Encryption Keys (KEKs):** DEKs worden versleuteld (gewrapt) door KEKs. KEKs zijn niet klant-specifiek, maar per service [11](#page=11) [12](#page=12). * **Keystore:** Een centrale repository voor het opslaan van KEKs. Dit maakt beheer op schaal beheersbaar en biedt een centraal controlepunt [12](#page=12). * **Sleutelgeneratie:** KEKs worden gegenereerd met een Google-specifieke RNG, gebaseerd op NIST 800-90Ar1 CTR-DRBG, en genereren een AES-256 KEK [12](#page=12). * **Veiligheid:** KEKs zijn niet exporteerbaar uit Keystore; encryptie/decryptie gebeurt binnen Keystore, wat lekken voorkomt en audit trails mogelijk maakt [12](#page=12). #### 1.3.4 Schijfencryptie Schijfencryptie is een veelvoorkomende methode om data op apparaten te beschermen. * **Windows: Bitlocker:** Gebruikt AES met CBC, willekeurige IV, en AES-XTS. Keuze uit 128- of 256-bits sleutelgrootte en 128-bits blokgrootte [13](#page=13). * **macOS: Filevault:** Gebruikt AES-XTS met een 256-bits sleutel en 128-bits blokgrootte [13](#page=13). * **VeraCrypt/TrueCrypt containers:** Omsluit data in een container die op meerdere besturingssystemen toegankelijk is. Biedt geen multi-user schrijftoegang en vereist het delen van wachtwoorden. Ondersteunt diverse encryptie-algoritmen (AES, Serpent, Twofish, Camellia, Kuznyechik) en XTS-modus. Maakt gebruik van PBKDF2 met een 512-bits salt. Biedt plausibele ontkenning [13](#page=13). * **Linux:** Gebruikt LUKS en dm-crypt [13](#page=13). * **iOS:** Gebruikt AES-256 met XTS-modus vanaf de A8-processor. Sleutels zijn niet toegankelijk voor software of firmware [14](#page=14). * **Android:** Gebaseerd op Linux dm-crypt met AES-256 en XTS-modus. Sleutels worden in software opgeslagen, wat een fundamentele zwakte blijft ondanks patchen van bekende kwetsbaarheden. Opmerkelijk is dat als het mobiele apparaat is ingeschakeld en ontgrendeld, de data transparant ontsleuteld beschikbaar is. In oudere implementaties konden sleutels in het RAM blijven, zelfs wanneer het apparaat vergrendeld was [14](#page=14). * **Mobiele containers:** Een geauthenticeerde, versleutelde ruimte op een mobiel apparaat om gevoelige bedrijfsgegevens te isoleren van persoonlijke data [14](#page=14). * **Doel:** Isolatie van applicaties, beperken van functies, selectief wissen van data in de container, op afstand wissen van apparaten, en beleidsregels toepassen [14](#page=14). * **Mobile Application Management (MAM):** Omvat beveiligde containers, beveiligingsbeleid, en whitelisting van applicaties [14](#page=14). * **Voordelen van mobiele containers:** Apparaten worden gekend en getraceerd; alleen geautoriseerde apparaten verbinden met het netwerk; beveiligingssystemen scheiden bedrijfs- en persoonlijke data; op afstand wissen van data is mogelijk; integratie met bedrijfsdirectory's; enterprise app store; AES-256 encryptie van data at rest en in transit; DLP-ondersteuning; beleidsregels voor jailbroken/gerootte apparaten [15](#page=15). Het is belangrijk om onderscheid te maken tussen schijfencryptie en bestandsencryptie. Bestandsencryptie wordt per bestand geconfigureerd en vereist aparte sleutels en gedegen sleutelbeheer [15](#page=15). #### 1.3.5 Database encryptie Encryptie voor databases kan plaatsvinden op verschillende lagen, van de database-engine tot de applicatielaag [16](#page=16). * **API-methode:** Encryptie vindt plaats in de applicatielaag met behulp van een encryptieagent. Query's naar versleutelde kolommen moeten in de applicatie worden afgehandeld [16](#page=16). * **Plug-in methode:** Een encryptiepakket (module) wordt aan het DBMS gekoppeld. Deze methode werkt onafhankelijk van de applicatie en vereist minder codewijzigingen. Het is flexibel en toepasbaar op zowel commerciële als open-source databases [16](#page=16). * **TDE (Transparent Data Encryption):** Een encryptie-/decryptie-engine wordt direct in de database-engine geïnstalleerd. Dit gebeurt op het laagste systeemniveau en vereist geen aanpassing van de databankomgeving of applicatiecode. Het beheer is eenvoudig. Een kritiek punt is dat het niet duidelijk is welk probleem TDE oplost, aangezien er geen sleutels aan de clientzijde nodig zijn en alle encryptie/decryptie automatisch verloopt. Query's op een versleutelde database blijven een uitdaging bij alle encryptiemethoden [17](#page=17). ### 1.4 Resterende uitdagingen * **Quantum computing:** De dreiging van kwantumcomputers die huidige cryptografische standaarden kunnen breken, is een belangrijke toekomstige uitdaging [2](#page=2). * **Metadata:** Het beschermen van metadata blijft een uitdaging, ondanks inspanningen zoals chunking [2](#page=2). * **Veilige opslag en sleutelbeheer:** De vraag waar sleutels veilig opgeslagen moeten worden, blijft relevant. Vaak leidt een oplossing tot het overdragen van controle aan een vertrouwde partij [2](#page=2). * **Berekeningen op versleutelde data:** Zoals eerder genoemd, is dit nog een onopgelost probleem met aanzienlijke overhead [2](#page=2) [3](#page=3). > **Tip:** Begrijp het verschil tussen de drie staten van data: in transit, at rest, en in gebruik. Elk vereist specifieke encryptiestrategieën. > **Tip:** Bij het evalueren van encryptieoplossingen is het cruciaal om het dreigingsmodel van de gebruiker of organisatie in overweging te nemen. Niet alle oplossingen zijn geschikt voor elke situatie. > **Tip:** De opkomst van kwantumcomputers vormt een toekomstige uitdaging voor de meeste huidige cryptografische algoritmen. Post-kwantum cryptografie is een actief onderzoeksgebied. --- # Hybride encryptie: de combinatie van symmetrische en asymmetrische cryptografie Hybride encryptie combineert de snelheid van symmetrische cryptografie met de flexibiliteit van asymmetrische cryptografie voor effectief sleutelbeheer [4](#page=4). ### 2.1 De noodzaak voor hybride encryptie Symmetrische encryptie, zoals AES, is significant performanter dan asymmetrische encryptie (tot wel duizend keer sneller). Echter, het veilig delen van de symmetrische sleutel vormt een uitdaging. Asymmetrische encryptie, hoewel langzamer, biedt een oplossing voor dit sleutelbeheerprobleem [4](#page=4). ### 2.2 Werkingsprincipe van hybride encryptie In de praktijk wordt een willekeurige sleutel $K$ gegenereerd voor symmetrische encryptie, bijvoorbeeld met AES. Vervolgens wordt deze sleutel $K$ versleuteld met behulp van asymmetrische encryptie, zoals RSA. De ontvanger gebruikt dan de bijbehorende private sleutel om de symmetrische sleutel $K$ te ontsleutelen, waarna deze $K$ gebruikt kan worden om de eigenlijke data te ontsleutelen. Dit proces combineert de snelheid van symmetrische encryptie voor dataversleuteling met de veiligheid van asymmetrische encryptie voor sleuteluitwisseling [4](#page=4). > **Tip:** Hybride encryptie maakt het mogelijk om de voordelen van beide cryptografische methoden te benutten: hoge performance voor het versleutelen van grote hoeveelheden data en een veilig mechanisme voor het uitwisselen van de benodigde sleutels. ### 2.3 Veiligheidsoverwegingen en aanvullende mechanismen Organisaties willen het risico minimaliseren dat het verlies van een persoon of een enkele sleutel leidt tot onbeschikbaarheid van data. Om dit te adresseren, wordt vaak een tweede versleutelingslaag toegevoegd. Deze laag maakt het mogelijk voor een aangewezen sleutelherstelagent, wiens private sleutel zeer goed beschermd is, om de data in geval van nood te ontsleutelen. Dit kan verder versterkt worden door procedures, eventueel in combinatie met technologie, die vereisen dat bijvoorbeeld twee personen de autorisatie voor sleutelherstel moeten geven [4](#page=4). ### 2.4 Vergelijking van cryptografische algoritmen (ter context) * **Symmetrisch:** * DES: Ouder algoritme, werkt met blokken van 64 bits en een sleutel van 56 bits [4](#page=4). * AES: Werkt met blokken van 128 bits. AES-128 gebruikt een 128-bits sleutel, terwijl AES-256 eveneens met 128-bits blokken werkt maar een 256-bits sleutel gebruikt [4](#page=4). * **Asymmetrisch:** * RSA: Populaire bitlengtes zijn 2048 en 4096 bits [4](#page=4). * ECC (Elliptical Curve Cryptography): Gebruikelijke sleutellengtes zijn 256 of 512 bits, maar wordt voornamelijk gebruikt voor digitale handtekeningen en zelden voor encryptie [4](#page=4). --- # Cloudopslag en encryptie: server-side versus client-side Deze sectie vergelijkt server-side en client-side encryptie voor cloudopslag, waarbij de focus ligt op de verschillen in sleutelbeheer, encryptieprocessen en de bijbehorende voor- en nadelen. ### 3.1 Server-side encryptie Bij server-side encryptie worden de daadwerkelijke encryptie- en decryptieoperaties uitgevoerd op de server zelf. De server beheert ook de cryptografische sleutels, hoewel deze versleuteld zijn en alleen gedecodeerd kunnen worden met behulp van het wachtwoord van de gebruiker via een wachtwoordgebaseerde sleutelafleidingsfunctie (key derivation function) [5](#page=5). #### 3.1.1 Voordelen van server-side encryptie * **Geen toegang voor beheerders:** Zelfs systeembeheerders kunnen de versleutelde bestanden niet lezen [5](#page=5). * **Gecentraliseerd beheer:** De encryptie- en decryptieprocessen zijn volledig gecentraliseerd, wat voordelig is voor cloudopslagontwikkelaars met adequate cryptografische kennis [5](#page=5). * **Veilig sleutelbeheer:** Sleutelbeheer is gecentraliseerd en sleutels zijn toegankelijk op een sterk beveiligde server [5](#page=5). * **Geavanceerde authenticatie:** Server-side wachtwoorden maken geavanceerde authenticatiemethoden, zoals multi-factor authenticatie, mogelijk [5](#page=5). #### 3.1.2 Nadelen van server-side encryptie * **Vertrouwen in servercode:** Gebruikers moeten de code op de server vertrouwen, omdat deze mogelijk meer doet dan verwacht, zoals het opslaan van gebruikerswachtwoorden [5](#page=5). * **Communicatie niet altijd versleuteld:** Omdat encryptie alleen in de cloud plaatsvindt, is de communicatie tussen desktop en cloud niet versleuteld. Hoewel TLS gebruikt kan worden, is dit mogelijk niet voldoende [5](#page=5). * **Geen encryptie op de desktop:** Eenmaal op de desktop is er geen verdere encryptie meer, wat van toepassing is op gesynchroniseerde kopieën en caches [6](#page=6). * **Risico op overheidsvorderingen:** Het is mogelijk dat wetshandhavers toegang eisen tot de cloud en de provider dwingen surveillance-software te installeren [6](#page=6). > **Tip:** De keuze voor server-side encryptie hangt sterk af van het specifieke dreigingsmodel van de gebruiker. Voorbeelden van cloudopslag die server-side encryptie gebruiken zijn Owncloud en Nextcloud [6](#page=6). ### 3.2 Client-side encryptie Bij client-side encryptie vinden alle encryptie- en decryptieoperaties plaats op de client (het apparaat van de gebruiker). De cloud ontvangt enkel versleutelde gegevens. Dit kan via een aparte applicatie of via browserplugins gebeuren [7](#page=7). #### 3.2.1 Voordelen van client-side encryptie * **Maximale privacy:** Niemand op de server, zelfs de servercode niet, kan betekenisvolle gegevens uit de cloud ophalen [7](#page=7). * **Verborgen metadata:** In combinatie met chunking kunnen zelfs metadata verborgen blijven voor de cloudprovider [7](#page=7). #### 3.2.2 Nadelen van client-side encryptie * **Opslag van sleutels:** De sleutels worden op het eindpunt (client) opgeslagen, wat als het zwakste punt van systemen wordt beschouwd [7](#page=7). * **Tijdelijke ontsleuteling:** Data moet voor gebruik altijd tijdelijk ontsleuteld worden op de client, waar het ook kan blijven [7](#page=7). * **Delen van data:** Delen van data tussen verschillende gebruikers is onmogelijk of zeer complex [7](#page=7). * **De-duplicatie:** De-duplicatie (het herkennen en voorkomen van opslag van dubbele bestanden) is onmogelijk of erg moeilijk [7](#page=7). * **Wachtwoordherstel:** Wachtwoordherstel kan lastig zijn, hoewel sommigen dit als een voordeel zien [7](#page=7). * **Vertrouwen in clientsoftware:** Gebruikers moeten nog steeds de ontwikkelaar van de client-side software vertrouwen [7](#page=7). * **Browserplugins/JavaScript:** Bij gebruik van browserplugins of JavaScript in de browser is dit risico groter, omdat deze zonder medeweten van de gebruiker worden bijgewerkt [7](#page=7). * **Zichtbare metadata:** Metadata kan nog steeds zichtbaar zijn, tenzij er chunking wordt toegepast [7](#page=7). > **Tip:** Client-side encryptie wordt vaak als de betere optie beschouwd, maar de effectiviteit hangt wederom af van het dreigingsmodel. Voorbeelden van clouddiensten die client-side encryptie implementeren zijn Cryptomator, Seafile, Spideroak en SparkleShare. VeraCrypt is geen cloudoplossing, maar een container voor desktopgebruik [7](#page=7) [8](#page=8). ### 3.3 Details van Cryptomator implementatie Cryptomator biedt client-side encryptie en verbergt metadata voor de server, hoewel bestandsgrootte en datums wel zichtbaar kunnen blijven. Bestanden worden opgesplitst in chunks, waardoor de metadata van versleutelde bestanden geen bruikbare informatie oplevert [9](#page=9). * **Sleutelafleiding:** Cryptomator gebruikt `scrypt` als wachtwoordgebaseerde sleutelafleidingsfunctie [9](#page=9). * **Key Wrap:** De Key Wrap modus van AES wordt gebruikt om sleutels te beheren. Dezelfde KEK (Key Encryption Key) wordt gebruikt om de encryptiesleutel en de MAC-sleutel af te leiden, wat authenticatie garandeert [9](#page=9). * **Master Keys:** Een KEK wordt afgeleid via `scrypt` en de masterkeys worden versleuteld met AES Key Wrap. De gewrapte sleutels en benodigde parameters worden opgeslagen in een JSON-bestand. Bij het ontgrendelen wordt de KEK gebruikt om de masterkeys te ontwarren (decoderen) [9](#page=9). * **Gebruikers- en apparaatsleutels:** Bij de eerste login genereert elke gebruiker een nieuw EC-sleutelpaar. De private sleutel wordt versleuteld met zowel de Account Key als de Device Key van elk apparaat van de gebruiker. Elk apparaat heeft een eigen sleutelpaar dat veilig op het apparaat wordt bewaard [9](#page=9). #### 3.3.1 Bestandsencryptie in Cryptomator * **Bestandsheader:** De bestandsheader bevat metadata voor contentencryptie [10](#page=10). * **Contentencryptie:** De encryptiesleutel versleutelt de contentkey naar een ciphertext payload en tag. Deze contentkey wordt vervolgens gebruikt voor de encryptie van de eigenlijke content [10](#page=10). * **Chunking:** Bestanden worden opgesplitst in chunks en versleuteld met AES in GCM modus. Eerdere versies gebruikten AES-CTR met HMAC; nu wordt AES-GCM gebruikt [10](#page=10). * **Bestandsnamen:** Duidelijke (cleartext) bestandsnamen worden versleuteld met AES-SIV. De versleutelde bestandsnaam wordt gebruikt om een bestand of map te creëren [10](#page=10). * **Lange bestandsnamen:** Als een versleutelde bestandsnaam (met `.c9r` extensie) langer is dan 220 karakters, wordt een bestand of map aangemaakt met de kortere SHA-1 hash en de extensie `.c9s`. Een bijkomend bestand `name.c9s` bevat de originele bestandsnaam [10](#page=10). * **Auditresultaten:** Een audit in 2017 door Cure53 wees uit dat de standaard bedrijfsmodus in de gebruikte bibliotheek AES/ECB was [10](#page=10). ### 3.4 Google's "Encryption at Rest" strategie Google implementeert meerdere lagen van encryptie voor gebruikersdata in hun datacenters [11](#page=11). * **Data opdeling:** Data wordt opgedeeld in subfile chunks van enkele gigabytes. Elke chunk wordt op het opslagniveau versleuteld met een individuele Data Encryption Key (DEK). Zelfs als chunks van dezelfde klant afkomstig zijn of op dezelfde machine staan, hebben ze verschillende DEK's. Bij updates wordt een nieuwe sleutel gebruikt [11](#page=11). * **Risicobeperking:** Door elke chunk met een aparte sleutel te versleutelen, beperkt een compromittering van een DEK het risico tot enkel die specifieke datachunk [11](#page=11). * **Replicatie:** Data wordt gerepliceerd in versleutelde vorm voor back-up en disaster recovery [11](#page=11). * **Toegang vereisten:** Om klantdata te benaderen, moet een aanvaller alle relevante opslagchunks én de bijbehorende encryptiesleutels kennen [11](#page=11). * **AES-256:** DEK's gebruiken standaard AES-256 voor encryptie op opslagniveau [11](#page=11). * **KEK's (Key Encryption Keys):** DEK's worden dichtbij de data opgeslagen, maar zijn zelf versleuteld (gewrapt) door een Key Encryption Key (KEK). KEK's zijn niet klant-specifiek, maar worden per service beheerd en centraal opgeslagen in Keystore. Dit maakt opslag op schaal beheersbaar en biedt een centraal punt voor toegangscontrole [12](#page=12). * **Generatie van sleutels:** DEK's worden gegenereerd door de storage systemen met behulp van Google's cryptografische bibliotheek. KEK's worden voornamelijk binnen Keystore gegenereerd, maar ook binnen storage services. Ze worden gegenereerd met een Google-ontwikkelde RNG die gebaseerd is op NIST 800-90Ar1 CTR-DRBG en produceert AES-256 KEK's [12](#page=12). * **Keystore functionaliteit:** Keystore is specifiek ontworpen voor KEK-beheer. KEK's die door storage systemen worden gebruikt, zijn niet exporteerbaar uit Keystore; alle encryptie- en decryptieoperaties met deze sleutels moeten binnen Keystore plaatsvinden. Dit voorkomt lekken en maakt auditing van sleutelgebruik mogelijk [12](#page=12). * **Voorkeursalgoritme:** Het voorkeursalgoritme voor encryptie is AES-SJH [12](#page=12). --- # Schijfencryptie op verschillende besturingssystemen Schijfencryptie speelt een cruciale rol in het beveiligen van gevoelige gegevens op diverse besturingssystemen en mobiele apparaten, door middel van zowel volledige schijfencryptie als containeroplossingen [13](#page=13). ### 4.1 Volledige schijfencryptie Volledige schijfencryptie (Full Disk Encryption - FDE) versleutelt de gehele opslag van een apparaat, waardoor de gegevens ontoegankelijk zijn voor onbevoegden zonder de juiste sleutel of wachtwoord [13](#page=13). #### 4.1.1 Implementaties op besturingssystemen * **Windows: BitLocker** * Gebruikt AES (Advanced Encryption Standard) encryptie [13](#page=13). * Ondersteunt verschillende modi, waaronder CBC (Cipher Block Chaining) en AES-XTS (XEX-based tweaked-codebook mode) [13](#page=13). * Maakt gebruik van een willekeurige initialization vector (IV) [13](#page=13). * Biedt keuze tussen sleutelgroottes van 128-bit en 256-bit [13](#page=13). * Heeft een blockgrootte van 128-bit [13](#page=13). * **macOS: FileVault** * Gebruikt AES-XTS encryptie [13](#page=13). * Maakt gebruik van een 256-bit sleutelgrootte [13](#page=13). * Heeft een blockgrootte van 128-bit [13](#page=13). * Vanaf de A8 processor wordt XTS mode of operation gebruikt [14](#page=14). * De encryptiesleutels kunnen niet door software of firmware worden gelezen [14](#page=14). * **Linux: LUKS en dm-crypt** * Linux gebruikt voornamelijk LUKS (Linux Unified Key Setup) in combinatie met dm-crypt voor schijfencryptie. Dit is een standaard methode voor block device encryptie op Linux systemen [13](#page=13). #### 4.1.2 Mobiele apparaten * **iOS (iPhone en iPad)** * Gebruikt AES-256 encryptie [14](#page=14). * Vanaf de A8 processor wordt XTS mode of operation gebruikt [14](#page=14). * De encryptiesleutels kunnen niet door software of firmware worden gelezen [14](#page=14). * Het is essentieel om een wachtwoord (PIN-code of alfanumeriek wachtwoord) te hebben [13](#page=13). * **Android** * Is gebaseerd op Linux's dm-crypt [14](#page=14). * Gebruikt AES-256 encryptie [14](#page=14). * Maakt gebruik van XTS mode of operation [14](#page=14). * De encryptiesleutels worden opgeslagen in software [14](#page=14). * Hoewel bekende kwetsbaarheden om de sleutel te benaderen zijn gepatcht, blijft een fundamentele zwakte bestaan [14](#page=14). * In oudere implementaties van Android konden sleutels in RAM blijven, zelfs wanneer het apparaat vergrendeld was [14](#page=14). > **Tip:** Op mobiele apparaten wordt de encryptie transparant uitgevoerd wanneer het apparaat ontgrendeld is. Dit betekent dat de gegevens op dat moment ongecodeerd lijken, zolang het apparaat ontgrendeld is [14](#page=14). ### 4.2 Containeroplossingen Containeroplossingen creëren versleutelde virtuele schijven (containers) die binnen een bestaand besturingssysteem kunnen worden gemount [13](#page=13). #### 4.2.1 VeraCrypt (voorheen TrueCrypt) * Maakt het mogelijk om versleutelde containers toegankelijk te maken vanaf meerdere besturingssystemen [13](#page=13). * Ondersteunt verschillende encryptie-algoritmen, waaronder AES, Serpent, Twofish, Camellia en Kuznyechik [13](#page=13). * Maakt gebruik van de XTS mode of operation [13](#page=13). * Maakt gebruik van PBKDF2 met een 512-bit salt voor wachtwoordverificatie [13](#page=13). * **Beperking:** Biedt geen ondersteuning voor multi-user write access, en wachtwoorden moeten gedeeld worden [13](#page=13). * Ondersteunt het concept van "plausible deniability" (aannemelijke ontkenning) [13](#page=13). #### 4.2.2 Mobiele containers en Mobile Application Management (MAM) Een mobiele container is een geauthenticeerd, versleuteld gebied op een mobiel apparaat dat gevoelige bedrijfsgegevens isoleert van persoonlijke informatie [14](#page=14). * **Doel van containerization:** * Applicaties isoleren om interactie met malware, indringers, systeemresources of andere applicaties te voorkomen [14](#page=14). * Het beveiligen van gevoelige informatie binnen de container [14](#page=14). * Het uitschakelen van bepaalde functies van apps binnen de container [14](#page=14). * Informatie binnen de container wissen zonder persoonlijke gegevens te beïnvloeden [14](#page=14). * Apparaten op afstand wissen in geval van verlies of diefstal [14](#page=14). * Beleid of acties toepassen op alle apparaten [14](#page=14). * **Mobile Application Management (MAM):** * Omvat beveiligde containers [14](#page=14). * Stelt beveiligingsbeleid op [14](#page=14). * Maakt whitelisting van specifieke applicaties mogelijk [14](#page=14). * **Voordelen van mobiele containers:** * Alle gebruikte apparaten binnen het bedrijf zijn bekend en worden gevolgd [15](#page=15). * Alleen geautoriseerde apparaten kunnen verbinding maken met het bedrijfsnetwerk [15](#page=15). * Gebruikers die verbinding maken vanaf openbare Wi-Fi-toegangspunten worden gecontroleerd [15](#page=15). * Apparaten hebben beveiligingssystemen die bedrijfsapplicaties scheiden van persoonlijke informatie [15](#page=15). * Verloren of gestolen apparaten kunnen op afstand worden gewist van gevoelige gegevens [15](#page=15). * Authenticatie kan geïntegreerd worden met bedrijfs AD/LDAP [15](#page=15). * Beschikken over een enterprise app store [15](#page=15). * Bieden AES-256 encryptie van gegevens opgeslagen en in transit [15](#page=15). * Ondersteunen Data Loss Prevention (DLP), met restricties voor offline bekijken, kopiëren/plakken, printen en e-mailen [15](#page=15). * Kunnen beleid afdwingen zoals het detecteren/beperken van jailbroken of gerootte apparaten, of onbeveiligde apparaten of apps [15](#page=15). * Bevatten vaak een specifieke e-mailapp [15](#page=15). > **Belangrijk onderscheid:** Het is cruciaal om onderscheid te maken tussen schijfencryptie (Full Disk Encryption) en bestandsencryptie. Bestandsencryptie wordt per bestand geconfigureerd, gebruikt doorgaans een hybride benadering, vereist aparte sleutels per bestand en een zorgvuldig sleutelbeheer [15](#page=15). #### 4.2.3 Algemene overwegingen voor mobiele encryptie * De prestaties van schijfencryptie zijn vandaag de dag geen beperkende factor meer [14](#page=14). * Er is geen reden om deze beveiligingstools vandaag de dag niet te gebruiken [14](#page=14). --- # Database encryptiemethoden Dit onderdeel van de studiehandleiding duikt dieper in de verschillende methoden voor database-encryptie, met specifieke aandacht voor hun implementatie en de impact ervan op gegevensbeveiliging en -beheer [16](#page=16) [17](#page=17). ### 5.1 Overzicht van encryptiemethoden Encryptie kan plaatsvinden op verschillende lagen, van de applicatie tot de database-engine zelf. De drie belangrijkste benaderingen die worden besproken zijn de API-gebaseerde methode, de plug-in methode en Transparent Data Encryption (TDE) [16](#page=16) [17](#page=17). ### 5.2 API-gebaseerde encryptie De API-gebaseerde encryptiemethode vindt plaats in de applicatielaag [16](#page=16). * **Implementatie:** Bij deze methode is een encryptieagent vereist om de encryptie toe te passen. Het encryptieproces vindt plaats *voordat* de gegevens de database binnenkomen [16](#page=16). * **Impact op queries:** Alle queries die verwijzen naar versleutelde kolommen moeten worden afgehandeld binnen de applicatie. Dit kan leiden tot complexere applicatielogica [16](#page=16). > **Tip:** Deze methode vereist een actieve rol van de applicatieontwikkelaar bij het implementeren en beheren van de encryptie. ### 5.3 Plug-in methode De plug-in methode houdt in dat een encryptiepakket of -module wordt gekoppeld aan het Database Management System (DBMS) [16](#page=16). * **Implementatie:** In tegenstelling tot de API-methode werkt het encryptiepakket onafhankelijk van de applicatie. Dit resulteert in minder aanpassingen aan bestaande queries en code [16](#page=16). * **Flexibiliteit:** Deze methode is flexibel en toepasbaar op zowel commerciële DBMS-systemen als open-source databases, wat het een veelgebruikte methode maakt [16](#page=16). * **Clientlaag aanpassingen:** Enkele wijzigingen op de clientlaag kunnen wel noodzakelijk zijn [17](#page=17). ### 5.4 Transparent Data Encryption (TDE) Transparent Data Encryption (TDE) is een encryptiemethode die direct in de database-engine zelf wordt geïnstalleerd [17](#page=17). * **Implementatie:** TDE opereert op het laagst mogelijke systeemsniveau. Het vereist geen aanpassingen aan de broncode van de databaseomgeving of de applicatie. Beheerders kunnen de encryptie/decryptie-engine eenvoudig installeren en beheren in de database, zonder extra acties op de webserver [17](#page=17). * **Gebruiksgemak:** Het voordeel van TDE is dat er geen sleutels aan de clientzijde nodig zijn en dat alle encryptie en decryptie automatisch verloopt [17](#page=17). * **Query-uitdagingen:** Hoewel TDE veel automatisering biedt, blijft het bevragen van een versleutelde database een algemene uitdaging bij alle encryptiemethoden [17](#page=17). > **Tip:** TDE is vaak de voorkeurskeuze voor organisaties die een robuuste, transparante encryptie willen implementeren met minimale impact op bestaande applicaties en infrastructuur. > **Example:** Een bedrijf slaat gevoelige klantgegevens op. Door TDE te implementeren, worden deze gegevens automatisch versleuteld op schijfniveau. Applicaties die toegang hebben tot de database, hoeven geen aanpassingen te ondergaan, en de databasebeheerder kan de encryptiesleutels veilig beheren binnen de database-engine zelf [17](#page=17). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | Symmetrische encryptie | Een cryptografische methode waarbij dezelfde sleutel wordt gebruikt voor zowel versleuteling als ontsleuteling van data, wat doorgaans veel sneller is dan asymmetrische encryptie. | | Asymmetrische encryptie | Een cryptografisch systeem dat een paar sleutels gebruikt: een publieke sleutel voor versleuteling en een private sleutel voor ontsleuteling, wat essentieel is voor veilige sleuteluitwisseling en digitale handtekeningen. | | TLS 1.3 | Transport Layer Security versie 1.3, een recent protocol dat de veiligheid en prestaties van internetcommunicatie aanzienlijk verbetert door versleuteling tijdens de dataoverdracht. | | AES | Advanced Encryption Standard, een veelgebruikte symmetrische encryptie-algoritme dat blokken van 128 bits versleutelt met sleutellengtes van 128, 192 of 256 bits. | | AES-GCM | AES in Galois/Counter Mode, een cryptografische modus die zowel de vertrouwelijkheid (authenticiteit) als de integriteit van data biedt, vaak gebruikt in moderne versleutelingsprotocollen. | | AES-CTR | AES in Counter Mode, een symmetrische encryptiemodus die de data versleutelt door een teller te versleutelen en het resultaat bit-wise XOR-te vergelijken met de plaintext. | | HMAC | Hash-based Message Authentication Code, een algoritme dat een cryptografische hashfunctie combineert met een geheime sleutel om de data-integriteit en authenticiteit te waarborgen. | | RSA | Rivest–Shamir–Adleman, een veelgebruikt asymmetrisch encryptie-algoritme dat populair is voor veilige gegevensoverdracht en digitale handtekeningen, vaak met sleutellengtes zoals 2048 of 4096 bits. | | ECC | Elliptische curve cryptografie, een asymmetrisch cryptografisch systeem dat gebaseerd is op de algebra van elliptische krommen over eindige lichamen, efficiënter dan RSA bij vergelijkbare beveiligingsniveaus. | | KEK | Key Encryption Key (Sleutel Encryptie Sleutel), een sleutel die wordt gebruikt om andere cryptografische sleutels te versleutelen, vaak in een hiërarchisch sleutelbeheersysteem. | | DEK | Data Encryption Key (Data Encryptie Sleutel), de sleutel die direct wordt gebruikt voor het versleutelen en ontsleutelen van de daadwerkelijke data. | | Server-side encryptie | Een methode waarbij de encryptie- en ontsleutelingsbewerkingen plaatsvinden op de server, waarbij de server ook de sleutels beheert, wat kan leiden tot vertrouwensproblemen met de serverbeheerder. | | Client-side encryptie | Een methode waarbij de encryptie- en ontsleutelingsbewerkingen plaatsvinden op het apparaat van de gebruiker, waardoor de data versleuteld de cloud bereiken en de gebruiker meer controle heeft over de sleutels. | | scrypt | Een wachtwoordgebaseerde sleutelafleidingsfunctie die ontworpen is om bestand te zijn tegen brute-force aanvallen door hoge geheugenvereisten te stellen, vaak gebruikt voor het afleiden van encryptiesleutels uit wachtwoorden. | | AES-SIV | AES in Synthetic Initialization Vector mode, een encryptiemodus die de data-integriteit en vertrouwelijkheid biedt en zeer robuust is tegen aanvallen die gericht zijn op het manipuleren van de Initialisatie Vector (IV). | | TDE | Transparent Data Encryption, een methode voor database encryptie die direct in de database-engine is geïntegreerd en die de data op schijf versleutelt zonder dat applicaties of queries gewijzigd hoeven te worden. |