💻 informatica

ChunkGuard: a user-space secure file storage system with chunk- level encryption and integrity protection

ChunkGuard is een beveiligd bestandopslagsysteem in de user-space dat op chunk-niveau AES-128-CTR-encryptie en HMAC-SHA256-integriteitsverificatie gebruikt om de vertrouwelijkheid van gegevens te beschermen en manipulatie te detecteren, waarbij functionele beveiliging wordt bereikt terwijl disk I/O als de primaire prestatiebottleneck wordt geïdentificeerd.

Oorspronkelijke auteurs: Biryomumeisho Joshua, Ocen Emmy Fred, Bbosa Denis, Fred Paul Mark Jjunju

Gepubliceerd 2026-10-22

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Biryomumeisho Joshua, Ocen Emmy Fred, Bbosa Denis, Fred Paul Mark Jjunju

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Wanneer we een digitaal bestand op een computer opslaan, gaan we er vaak van uit dat het veilig is, simpelweg omdat het op een harde schijf staat. Echter, als die schijf wordt gestolen, verloren gaat, of als iemand toegang krijgt door het gebruikelijke inlogscherm te omzeilen, kan de data binnenin als platte tekst worden gelezen, waardoor alles van persoonlijke foto's tot privédocumenten wordt blootgesteld. Om dit te stoppen, gebruiken experts op het gebied van beveiliging encryptie, een proces waarbij data wordt gehusseld zodat het eruitziet als willekeurige ruis voor iedereen zonder de juiste sleutel. Terwijl veel systemen volledige harde schijven of grote mappen beschermen, verkent een nieuwe aanpak genaamd ChunkGuard een andere strategie: het opdelen van één enkel bestand in vele kleine, onafhankelijke stukjes voordat ze worden vergrendeld. Deze methode beoogt niet alleen geheimhouding, maar ook een manier te bieden om te verifiëren dat de data niet stiekem is gewijzigd of ermee is geknoeid terwijl deze in opslag lag.

Onderzoekers aan de Universal Technology and Management University en de Mbarara University of Science and Technology bouwden een prototype systeem genaamd ChunkGuard om te testen of deze fijnmazige aanpak in de praktijk werkt. In plaats van een bestand als één groot blok data te behandelen, hakt hun systeem het in kleine, vast formaat stukjes die 'chunks' worden genoemd. Elk van deze stukjes wordt vervolgens individueel versleuteld met een unieke geheime sleutel en een willekeurig startgetal, wat ervoor zorgt dat zelfs als twee chunks identieke informatie bevatten, ze er volledig anders uitzien wanneer ze zijn vergrendeld. Om te garanderen dat de data betrouwbaar blijft, maakt het systeem ook een digitale zegel aan voor elk afzonderlijk stukje. Als zelfs maar een minuscuul deel van de data wordt gewijzigd of corrupt raakt, breekt deze zegel, wat het systeem waarschuwt dat er iets mis is. De onderzoekers voegden ook een strikte controle toe om te verzekeren dat alleen de persoon die eigenaar is van het bestand het kan openen, waarbij elk poging door onbevoegde gebruikers om de inhoud te bekijken wordt afgewezen.

Het team onderwierp dit systeem aan een reeks rigoureuze tests om te zien hoe goed het presteerde en hoe veilig het daadwerkelijk was. Ze voerden dertig verschillende scenario's uit, inclusief pogingen om het systeem te breken door de data te wijzigen of zich voor te doen als een andere gebruiker. In elk geval hield het systeem stand. Het detecteerde succesvol wanneer iemand probeerde te knoeien met de versleutelde data, en het blokkeerde correct iedereen die niet de eigenaar van het bestand was om de inhoud te lezen. Wanneer ze de snelheid maten waarmee het systeem werkte op een bestand van één megabyte, vonden ze dat het versleutelen van de data ongeveer 161 milliseconden duurde, terwijl het ontsleutelen sneller was en ongeveer 79 milliseconden in beslag nam. Het controleren van de data op manipulatie ging nog sneller en vereiste slechts ongeveer 17 milliseconden. Deze snelheden vertalen zich naar het verwerken van data met een snelheid van ongeveer 6,2 megabyte per seconde voor encryptie en 12,7 megabyte per seconde voor decryptie.

Misschien kwam de meest verrassende ontdekking wel door nauwkeurig te kijken naar waar het systeem zijn tijd aan besteedde. De onderzoekers verwachtten dat het complexe wiskundige werk van het husselen van de data het traagste deel zou zijn. In plaats daarvan ontdekten ze dat de eigenlijke handeling van het schrijven van de vele kleine stukjes naar de schijf de flessenhals was. Het proces van het maken en opslaan van deze individuele chunk-bestanden verbruikte bijna 79 procent van de totale tijd, terwijl de eigenlijke encryptie-wiskunde minder dan 18 procent in beslag nam. Deze bevinding suggereert dat de snelheid van het systeem niet wordt beperkt door hoe hard de computer moet nadenken om de data te vergrendelen, maar door hoe efficiënt hij duizenden kleine bestanden naar de opslag schijf kan schrijven. De studie merkte ook op dat hoewel het systeem goed functioneerde in deze gecontroleerde test, het nog niet klaar was voor gebruik in de echte wereld omdat het enkele geavanceerde veiligheidsfuncties mist die in volwassen commerciële systemen te vinden zijn, zoals het vermogen om meerdere gebruikers tegelijkertijd te laten werken of de bescherming van de eigen interne records.

De resultaten demonstreren dat het geheel mogelijk is om een veilig opslagsysteem te bouren dat elk klein stukje van een bestand controleert op zowel geheimhouding als integriteit. De studie benadrukt echter ook een praktische technische uitdaging: het opdelen van bestanden in te veel kleine stukjes kan het systeem vertragen, simpelweg vanwege de overhead van het beheren van zoveel aparte bestanden. De onderzoekers concluderen dat hoewel het concept van beveiliging op chunk-niveau solide is, toekomstige versies de stukjes efficiënter zouden moeten organiseren, bijvoorbeeld door ze in grotere containers te groeperen, om het systeem snel genoeg te maken voor dagelijks gebruik. Dit werk vervangt de bestaande beveiligingsinstrumenten niet, maar biedt een helder, gemeten kijk op hoe een specifieke ontwerpkeuze de prestaties en beveiliging beïnvloedt, en wijst de weg naar robuustere oplossingen voor de bescherming van data in rust.

Technische Samenvatting: ChunkGuard

Probleemstelling
Beveiliging van gegevens in rust (data-at-rest) is cruciaal omdat opslagmedia gecompromitteerd kunnen worden door diefstal, verlies of ongeautoriseerde directe toegang, waarbij conventionele beschermingen op applicatieniveau worden omzeild. Hoewel volwassen oplossingen zoals BitLocker, eCryptfs, Linux fscrypt en OpenZFS dit aanpakken op het niveau van volumes, bestandssystemen of datasets, is er een behoefte aan het evalueren van de haalbaarheid en de prestatiekarakteristieken van fijnmazige, beveiligde opslag in de gebruikersruimte (user-space). Specifiek onderzoekt deze studie of een prototype-architectuur die bestanden verdeelt in kleine, onafhankelijk beheerde chunks (blokken) effectief kan implementeren wat betreft vertrouwelijkheid, integriteitsverificatie en toegangscontrole, terwijl de specifieke prestatieknelpunten van een dergelijke aanpak worden geïdentificeerd.

Methodologie
De auteurs hebben ChunkGuard ontwikkeld, een prototype voor beveiligde bestandopslag in de gebruikersruimte, geïmplementeerd in Python met behulp van de PyCryptodome-bibliotheek. Het systeem werkt met een architectuur op chunk-niveau met de volgende ontwerpkenmerken:

Chunking: Bestanden worden verdeeld in vaste chunks van 1024 bytes.
Encryptie: AES-128 in Counter (CTR) modus biedt vertrouwelijkheid. Voor elke chunk wordt bij elke schrijfactie een unieke 128-bits sleutel en initialisatievector (IV) gegenereerd.
Integriteit & Authenticatie: Er wordt een HMAC-SHA256 berekend over elke ciphertext-chunk om manipulatie te detecteren. SHA-256 digests worden gebruikt voor consistentiecontroles van de master-metadata.
Toegangscontrole: Gebruikersauthenticatie wordt afgehandeld via PBKDF2-HMAC-SHA1 (20.000 iteraties) met een 32-bytes zout (salt). Eigendomstoetsen worden afgedwongen voordat de inhoud van de chunks wordt verwerkt; ongeautoriseerde gebruikers worden geweigerd vóór de decryptie.
Implementatieopmerking: Het prototype gebruikt hetzelfde per-chunk geheim voor zowel AES-CTR als HMAC, een ontwerpkeuze die wordt erkend als een beperking in de beveiligingsverharding (security-hardening) in plaats van een aanbevolen constructie.

Het systeem werd geëvalueerd via vier complementaire testgroepen:

Een geautomatiseerde suite van 30 gevallen die authenticatie, de levenscyclus van bestanden, toegangscontrole, detectie van manipulatie en systeemgezondheid beslaat.
Grenswaarden-testen (boundary testing) voor chunking-gedrag bij bestandsgroottes van 1 tot 5000 bytes.
Prestatietijdmetingen voor encryptie, decryptie en integriteitsverificatie op bestanden variërend van 16 bytes tot 1 MB.
Componentprofilering van het 1 MB encryptiepad om te isoleren hoeveel tijd wordt besteed aan I/O, cryptografische operaties en sleutelgeneratie.

Belangrijkste Resultaten

Functionele Correctheid: Alle 30 functionele en beveiligingsgeoriënteerde testgevallen zijn geslaagd. Het systeem handhaafde correct het eigendom, wees ongeautoriseerde toegang af en detecteerde opzettelijke wijzigingen in de ciphertext (bijv. single-byte flips) via HMAC-verificatie.
Efficiëntie van Chunking: Het systeem produceerde het theoretische minimum aantal chunks ( $\lceil \text{grootte}/1024 \rceil$ ) onder alle geteste grenswaarden.
Prestatiecijfers (1 MB bestand):
- Gemiddelde encryptietijd: 160,833 ms (Doorvoersnelheid: ~6,2 MB/s).
- Gemiddelde decryptietijd: 78,559 ms (Doorvoersnelheid: ~12,7 MB/s).
- Gemiddelde tijd voor integriteitsverificatie: 16,734 ms.
Prestatieknelpunt: Componentprofilering toonde aan dat opslag-I/O de dominante factor was, en niet de cryptografische berekening.
- Fysieke chunk-bestand schrijfacties: 145,17 ms (78,7% van de totale tijd).
- AES-128-CTR encryptie: 31,78 ms (17,2%).
- HMAC-SHA256 berekening: 5,61 ms (3,0%).
- Sleutel/IV generatie: 1,91 ms (1,0%).

Betekenis en Claims
Het artikel positioneert ChunkGuard niet als een productie-klaar vervanging voor gevestigde versleutelde bestandssystemen, noch als een bron van nieuwe cryptografische primitieven. In plaats daarvan is de primaire bijdrage een gemeten systeemobservatie die aantoont dat een applicatie in de gebruikersruimte succesvol chunk-niveau encryptie, expliciete integriteitscontrole en eigendomsafdwinging kan integreren in een reproduceerbaar prototype.

De meest significante empirische bevinding is dat de opslagorganisatie, in plaats van de uitvoering van de cijfers (ciphers), de grootste prestatiekosten veroorzaakt in deze fijnmazige architectuur. De studie concludeert dat hoewel de cryptografische implementatie haalbaar is, de overhead van het maken en schrijven van veel kleine chunk-bestanden de primaire bottleneck is. Dit leidt tot de engineeringhypothese dat toekomstige iteraties de logische verificatie op chunk-niveau moeten behouden, terwijl de fysieke opslag moet worden geconsolideerd in geïndexeerde containers of grotere objecten om de prestaties te verbeteren.

Beperkingen
De auteurs vermelden expliciet de volgende beperkingen:

Benchmarks waren beperkt tot 1 MB bestanden in een enkele ontwikkelomgeving, wat generalisatie naar grote bestanden, gelijktijdige workloads of andere hardware verhindert.
De metadata-opslag is niet versleuteld en bevat sleutelmateriaal, waardoor het prototype ongeschikt is voor productie als een aanvaller toegang heeft tot de applicatie-metadata.
Het gebruik van een gedeeld geheim voor zowel encryptie als authenticatie, samen met het gebrek aan concurrency-veiligheid en formele beveiligingsanalyse (bijv. fuzzing, crash-consistentie), beperkt de huidige toepasbaarheid van het systeem.
De recovery sidecar legt momenteel gevoelige informatie bloot en vereist een herontwerp.

Meer zoals dit