Solidariteit met Oekraïne. Service gratis aangeboden aan Oekraïense bedrijven zolang de oorlog duurt. Gratis toegang aanvragen
Maximalistische zero-knowledge · privébèta

Uw namen van secrets
zijn ook versleuteld.

De meeste B2B-secretsmanagers versleutelen de inhoud van de wachtwoorden rigoureus en laten toch op hun server de namen, de types en de bijbehorende URLs in klare tekst staan. Als de database lekt, leest de aanvaller de volledige kaart van uw activiteit zonder ook maar één waarde te hoeven ontsleutelen. ARDNTECH past de zero-knowledge toe op alle metadata: namen, kinds, URIs worden vanuit de browser versleuteld via OpenPGP SEIPDv2. De server slaat enkel een ondoorzichtige blob op.

Sluit u aan bij de privébèta Lees het threat model
OpenPGP SEIPDv2 ChaCha20-Poly1305 / AES-256 Versleutelde namen Versleutelde types Versleutelde URLs Geautomatiseerde rotatie
01 / Het probleem

Wat de meeste kluizen in klare tekst laten.

Wanneer men het over een "zero-knowledge"-manager heeft, denkt men onmiddellijk aan de waarde van het wachtwoord. Toch graviteren rondom deze waarde metadata die minstens even sprekend zijn: de naam van het secret, het type, het betrokken domein, de mappenboomstructuur. Veel producten versleutelen enkel de waarde en exposeren de rest aan hun server, om ergonomische redenen. De kosten worden zelden geëxpliciteerd.

Wat een databasedump kan onthullen zonder ook maar één waarde te ontsleutelen

Stel u voor dat een aanvaller toegang krijgt tot een volledige kopie van de database van een uitgever waarbij enkel de wachtwoordinhoud versleuteld is. Zonder zelfs de cryptografie aan te vallen, kan hij uw interne cartografie reconstrueren:

  • een secret met de naam "Production AWS - root - root account" in een map "DevOps / Cloud", eigendom van een CTO-account;
  • een secret met de naam "SAP HANA - prod EMEA" gedeeld met vier financeaccounts;
  • een secret met de naam "Bankrekening BNP - SCI X" gedeeld tussen twee bestuurders;
  • een secret met de naam "Gerechtelijk mandataris - dossier Y" van een advocatenkantoor;
  • URLs in klare tekst die verwijzen naar de interne tools: jira.entreprise.com, vpn.entreprise.com, kibana.entreprise.com.

De aanvaller heeft geen enkel wachtwoord ontsleuteld. Hij kent toch al uw stack, uw partners, uw gevoelige dossiers, en heeft alles wat nodig is om een zeer overtuigende phishingaanval op de juiste personen te richten. Dit is precies wat men een "nutteloos zero-knowledge"-lek noemt.

De naam vertelt alles

De naam is de eerste informatieregel: hij duidt de applicatie aan, het account, soms de omgeving. Een ijverige interne naamgevingsconventie stelt hem des te meer bloot. Zonder versleuteling wordt hij de index van uw organisatie.

Het type categoriseert het risico

Type credential, type certificaat, type API-sleutel, type TOTP-seed: elk geeft informatie over de gevoeligheid en over de mogelijke pivots. Een aanvaller sorteert in enkele seconden om de certificaten en de API-sleutels te isoleren.

De URL verraadt het ecosysteem

De hoofd- en alternatieve URLs beschrijven uw volledige technische stack en uw partnerrelaties. Ze stellen een aanvaller in staat uw perimeter in kaart te brengen zonder een enkel netwerkverzoek aan slachtofferzijde.

02 / Onze aanpak

Eén cryptografische envelop per entiteit.

Elk secret en elke map draagt twee ondoorzichtige kolommen aan serverzijde. De plaintext-inhoud, die de naam, het type en de templatereferenties bevat, wordt geserialiseerd in JSON en daarna aan browserzijde versleuteld via OpenPGP in SEIPDv2-modus, met dezelfde sleutel als die voor de versleuteling van de payload. De server ontsleutelt deze blobs nooit.

Plaintext

Metadatavelden

De geserialiseerde plaintext bevat het schema (metadata/v1 voor een secret, folder_metadata/v1 voor een map), de naam, de kind (credential, api_key, certificate, note, totp of org_template) en de eventuele referentie naar een organisatietemplate. Geen enkel van deze velden wordt door de server gelezen of gemanipuleerd.

Chiffrement

OpenPGP SEIPDv2 in de browser

De plaintext wordt versleuteld in OpenPGP RFC 9580, in SEIPDv2-modus, met een symmetrische cipher AES-256-GCM of ChaCha20-Poly1305 naar keuze van de client. De bewerking vindt plaats in de browser van de gebruiker via OpenPGP.js v6, geaudit door Cure53. Geen enkele serverafgeleide komt tussenbeide.

Stockage

Twee ondoorzichtige kolommen aan serverzijde

De server slaat twee kolommen per entiteit op: encrypted_metadata die het ge-armorde PGP-bericht bevat, en metadata_envelope die een minimale JSON-wrapper bevat (versie, algoritme en kopie van de ciphertext). Geen enkel intermediair veld beschrijft de inhoud in klare tekst.

Partage

Directe herversleuteling voor de ontvanger

Wanneer een secret wordt gedeeld, wordt de plaintext rechtstreeks opnieuw versleuteld naar de publieke sleutel van de ontvanger. Er bestaat geen intermediaire symmetrische sleutel om in transit te beschermen, noch een "mastersleutel" aan serverzijde die zichtbaar is voor een aanvaller. Minder oppervlak, meer kosten in het opnieuw uitgeven van blobs: een aangenomen architectuurkeuze.

Ontsleuteling aan browserzijde en aan extensiezijde

Op het moment van de weergave haalt de browser de ondoorzichtige enveloppen op, ontsleutelt ze via een SharedWorker die de privésleutel van de paginacontext isoleert, en cachet de plaintext in sessionStorage voor de duur van het tabblad. De cache wordt automatisch geleegd bij het vergrendelen van de kluis, bij de logout en bij het sluiten van het tabblad. De browserextensie volgt hetzelfde model in een toegewijde browser.storage.session-cache.

03 / Feitelijke vergelijking

Versleutelde metadata per uitgever.

De onderstaande tabel beschrijft, voor meerdere erkende uitgevers van de markt, de manier waarop de belangrijkste metadata volgens hun openbare documentatie worden opgeslagen. De algehele kwaliteit van de genoemde producten wordt niet in twijfel getrokken: de vergelijking betreft uitsluitend deze precieze perimeter. De informatie dateert van 2026-08-01 en kan snel evolueren.

Uitgever Naam van het secret Type / kind URL / URI
ARDNTECH Versleuteld aan browserzijde (OpenPGP SEIPDv2) Versleuteld aan browserzijde Versleuteld aan browserzijde
Bitwarden Volgens openbare documentatie: naam van het item in klare tekst opgeslagen in de database voor de functies van zoeken en autofill aan serverzijde. Type (login, card, identity, secure note) zichtbaar aan serverzijde. Bijbehorende URLs zichtbaar aan serverzijde.
1Password Metadata versleuteld in de openbare specificatie. Houdingspariteit op dit precieze veld. Versleuteld in de openbare specificatie. Versleuteld in de openbare specificatie.
Proton Pass Metadata versleuteld aan browserzijde in de openbare documentatie. Versleuteld aan browserzijde. Versleuteld aan browserzijde.
Dashlane Volgens openbare documentatie: naam van het item in klare tekst opgeslagen aan serverzijde voor het cross-device zoeken en de autofill. Type item zichtbaar aan serverzijde. Bijbehorende domeinen zichtbaar aan serverzijde.
NordPass Volgens openbare documentatie: naam en type geëxposeerd aan serverzijde voor het zoeken en de autofill geassisteerd door de dienst. Type geëxposeerd aan serverzijde. Bijbehorende domeinen geëxposeerd aan serverzijde.
Passbolt v5.4 et supérieur Versleutelde metadata (toegewijde envelope geïntroduceerd in v5.4). Houdingspariteit met ARDNTECH. Versleuteld. Versleuteld.

Bronnen: openbare productdocumentatie en whitepapers van de uitgevers geraadpleegd op de aangegeven datum. De aanwezigheid van een secret met een niet-versleutelde naam aan serverzijde is geen cryptografisch gebrek; het gaat om een productkeuze, gemotiveerd door de functies van serverzoeken en geassisteerde autofill. ARDNTECH en Passbolt maken de omgekeerde keuze: maximale vertrouwelijkheid, zoeken aan clientzijde na lokale ontsleuteling. Als informatie u onjuist lijkt, neem contact op met legal@aegirex.eu en deze pagina zal worden gecorrigeerd.

04 / Gedocumenteerde trade-off

De aangenomen UX-kosten.

Het versleutelen van de namen heeft zichtbare kosten aan ergonomiezijde. Wij verkiezen deze kosten te documenteren in plaats van ze te verdunnen in de marketingbelofte. De houding wordt geëxpliciteerd in het threat model van {{ app_name }}, sectie gewijd aan de aangenomen trade-offs.

Coût technique

Het serverzoeken is niet langer mogelijk

Geen enkele SQL-query LIKE of ORDER BY op de naam kan door de server worden geformuleerd: hij beschikt enkel over een ondoorzichtige blob. Elke filter-, sorteer- of zoekbewerking op de naam moet plaatsvinden na ontsleuteling, dus aan clientzijde. Het is een expliciete afstand van klassieke optimalisaties.

Mitigation

Clientscan na lokale ontsleuteling

ARDNTECH past het clientscannen toe: de SharedWorker ontsleutelt de enveloppen in batch bij het laden van de kluis, voedt een sessionStorage-cache en maakt een onmiddellijk zoeken via lokale filter op de ontsleutelde plaintext mogelijk. Voor een individuele kluis van 500 entries blijft de waargenomen latentie lager dan 250 milliseconden bij het eerste laden en nul daarna.

Limite haute

Zeer grote kluizen

Voorbij enkele duizenden secrets in eenzelfde organisatie wordt de kost van de batchontsleuteling merkbaar. Voor de betrokken organisaties zijn een strategie van lazy loading per map en een lokale index die tussen sessies persisteert in voorbereiding. Deze grens betreft niet de grote meerderheid van de B2B-toepassingen.

Posture

Threat model sectie 5.1

De sectie gewijd aan de geavanceerde vertrouwelijkheid van het threat model beschrijft deze trade-off in detail, neemt ze op in de STRIDE/LINDDUN-matrix en lijst de tegenmaatregelen op. De trade-off maakt deel uit van het expliciete productcontract. Geen enkel commercieel discours minimaliseert deze.

05 / Rotatie

Rotatie van de metadatasleutels.

De versleuteling van de metadata heeft op termijn enkel waarde als ze vergezeld gaat van een rotatieprocedure. Een intrekking van toegang, een vertrek van een werknemer, een vermoeden van compromittering verplichten ertoe de blobs opnieuw uit te geven om de sleutel uit te sluiten die ze niet langer hoeft te ontsleutelen.

Rotatie getriggerd door intrekking

Wanneer een deelactie wordt ingetrokken of een lid een organisatie verlaat, wordt automatisch een rotatiejob aangemaakt. Hij lijst alle betrokken secrets en mappen op. De geautoriseerde clients drainen de job, geven de blobs opnieuw uit zonder de ingetrokken sleutel en bevestigen aan de server.

Periodieke organisatierotatie

Een beheerder kan een volledige periodieke rotatie van de organisatie triggeren om een beleid "elke 90 dagen" of soortgelijk te respecteren. De job geeft alle metadata-enveloppen opnieuw uit zonder onderbreking van de dienst.

On-demand rotatie en vermoeden

Voor een specifiek secret of een specifieke map kan een beheerder een onmiddellijke rotatie aanvragen, hetzij in preventieve modus, hetzij in modus "vermoeden van compromittering". De reden wordt getypeerd in de HMAC-auditketen, wat de dringende rotaties onderscheidt van de hygiënerotaties.

Toegewijde auditketen

Elke stap (start van de job, verwerking van een item, voltooiing, mislukking, vervaltermijn) wordt opgenomen in de HMAC-SHA-256-keten met een toegewijde kind. De traceerbaarheid van de rotatie is opvorderbaar en verifieerbaar op hetzelfde niveau als de andere kritieke gebeurtenissen.

Pariteit met de Passbolt v5.6-rotatie

De rotatiecapaciteit van de metadata is geleverd in pariteit met versie 5.6 van Passbolt, die een soortgelijk model met gedeelde symmetrische sleutel aanbiedt. ARDNTECH maakt de keuze voor een architectuur zonder gedeelde symmetrische sleutel: elke blob wordt rechtstreeks versleuteld voor de publieke sleutel van elke ontvanger. Dit elimineert de "master key" als aanvalsdoelwit, in ruil voor herverzendkosten per ontvanger. Voor organisatiekluizen onder de 10.000 secrets is de meerkost verwaarloosbaar.

06 / Voor wie

Vier situaties waar het niet onderhandelbaar is.

Voor bepaalde organisaties is de naam van een secret geen metadatum maar een volwaardig gevoelig gegeven. Hier zijn vier beroepscategorieën waarvoor de versleuteling van de namen een toelatingsvoorwaarde is, geen bonusfunctie.

Bank en gereguleerde financiën

De naam van een account "HSM Swift-beheer" of "toegang traders desk EUR" in een lek volstaat om een gerichte aanval naar hoogst gevoelige activa te oriënteren, zonder dat enig wachtwoord is onthuld. De prudentiële regelgeving zet ertoe aan dit oppervlak te minimaliseren.

Advocatenkantoren

Het beroepsgeheim dekt het bestaan zelf van bepaalde klantrelaties en dossiers. Een naam van een secret van het type "Dossier bestuurder X - strafprocedure" in klare tekst gelaten aan serverzijde verraadt het bestaan van een procedure, wat de deontologie verbiedt te onthullen.

Defensiesector en gevoelige overheden

De operatoren van vitaal belang, de veiligheidsdiensten en bepaalde overheden verwerken van nature informatie waarvan de loutere lijst inlichtingen vormt die nuttig zijn voor een tegenstander. Niet-versleutelde metadata zijn onverenigbaar met de behoefte aan compartimentering.

Onderzoeksjournalisten

De naam van een bron, de titel van een lopend onderzoek, de URL van een waarschuwingsmeldsysteem: evenveel informatie die, geëxposeerd aan serverzijde, bronnen in gevaar brengt die beschermd worden door de wet op de bescherming van het bronnengeheim van journalisten.

07 / Beginnen

Maximalistische zero-knowledge,
standaard en zonder meerkosten.

De volledige versleuteling van de metadata is inbegrepen in alle ARDNTECH-aanbiedingen, inclusief het gratis plan. Geen upsell, geen betaalde module, geen optie om te activeren. Vraag toegang tot de privébèta aan om de houding op een pilotorganisatie te evalueren, of lees het volledige threat model om deze trade-off in de globale architectuur van de oplossing te situeren.

Sluit u aan bij de privébèta Lees het threat model
Namen, types en URLs versleuteld aan browserzijde
OpenPGP SEIPDv2, AES-256 of ChaCha20-Poly1305
Geen gedeelde symmetrische sleutel om op te richten voor een aanvaller
Rotatie getooled en getraceerd in de HMAC-auditketen
Inbegrepen vanaf het gratis plan, zonder betaalde optie