de laatste jaren heeft het world wide web een exponentiële groei doorgemaakt van hackers, malware, Ransomware en andere kwaadaardige software of partijen die voortdurend proberen een manier te vinden om onze persoonlijke gegevens te stelen: gezien dit scenario is het vanzelfsprekend dat het beveiligen van uw gegevens een van de belangrijkste taken werd die we zouden moeten prioriteren, ongeacht de rol die we gewoonlijk spelen. De algemene (en dringende) noodzaak om ongeoorloofde toegang tot persoonlijke, gevoelige en/of anderszins kritieke informatie te voorkomen is iets dat door iedereen moet worden erkend – eindgebruikers, serviceeigenaren, serverbeheerders enzovoort: de verschillen zijn meestal gerelateerd aan wat we moeten beschermen en hoe we dat moeten doen.

onnodig te zeggen dat het kiezen van de juiste manier om onze gegevens te beschermen vaak volgt op een goed uitgevoerde risicobeoordeling, gevolgd door een kosten-batenanalyse, wat een geweldige aanpak is om ons te helpen bij het vinden van de juiste technische en organisatorische maatregelen om in ons specifieke scenario te implementeren. Dit is ook de juiste manier om te handelen volgens de Algemene Verordening Gegevensbescherming (AVG), zoals vermeld in artikel 32 – beveiliging van de verwerking:

rekening Houdend met de stand van de techniek, de kosten van tenuitvoerlegging en de aard, de reikwijdte, de context en de doeleinden van de verwerking alsmede het risico van verschillende waarschijnlijkheid en de ernst van de rechten en vrijheden van natuurlijke personen, de verantwoordelijke en de bewerker zal passende technische en organisatorische maatregelen om te zorgen voor een veiligheidsniveau dat is afgestemd op de risico

Hier is een lijst van de meest voorkomende technische en organisatorische maatregelen voor de bescherming en beveiliging van de gegevens van tegenwoordig:

  • toegangscontrole: Bescherm alle fysieke toegang tot uw server, client en/of Data kamers met sleutels, chipkaarten, muren, kluisjes, alarmen en dergelijke.
  • minimalisering: zorg ervoor dat alle geautoriseerde partijen alleen toegang hebben tot de gegevens die specifiek verband houden met hun specifieke taken en/of autorisatie, zonder dat zij iets anders mogen zien.
  • integriteit: Bescherm uw gegevens tegen onopzettelijk verlies, vernietiging of schade met behulp van geschikte tegenmaatregelen (brand/overstroming sensoren, noodherstel en dergelijke).
  • pseudonimisering: Vervang gebruikersgerelateerde gegevens door willekeurige, anonieme tekstblokken, zodat de eigenaar de gegevens nog steeds kan bewaren (voor statistische doeleinden) en ze tegelijkertijd kan verwijderen van persoonlijke gegevens.
  • versleuteling tijdens het transport: zorg ervoor dat de gegevens altijd worden verzonden met behulp van sterke versleutelingsstandaarden tijdens het transport (SSL/TLS-certificaten) en via beveiligde verbindingen: Dit geldt ook voor elke vorm van website en webgebaseerde dienst die formulieren, inlogschermen, Upload-/downloadmogelijkheden enzovoort bevat.
  • versleuteling tijdens rustperiode: Bescherm uw lokale gegevensopslageenheden (inclusief die welke worden gebruikt door servers en desktop & mobiele clients) met een sterke versleutelingsstandaard in rust; zorg ervoor dat de gegevens die zijn opgeslagen in Saas en cloudgebaseerde services ook in rust worden versleuteld.
  • vertrouwelijkheid: voorkom ongeoorloofde of onrechtmatige verwerking door het implementeren van concepten zoals scheiding van zaken & scheiding van plichten, afdwingen van wachtwoordbeleid, enzovoort.
  • mogelijke nuttige toepassing: Zorg ervoor dat alle relevante gegevens onderworpen zijn aan regelmatige back-ups en zorg er ook voor om ze regelmatig te controleren om ervoor te zorgen dat de gegevens succesvol kunnen worden opgehaald.
  • evaluatie: het hele systeem regelmatig aan technische evaluaties onderwerpen, audits door derden uitvoeren, een doeltreffende reeks veiligheidsindicatoren vaststellen, enzovoort.

In dit artikel gaan we het hebben over twee van deze technische maatregelen: encryptie in-transit en encryptie in-rest, waarbij de andere onderwerpen voor verdere artikelen worden overgelaten.

Inleiding: de drie fasen van digitale gegevens

het eerste wat we moeten doen is opsommen hoeveel “staten” digitale gegevens daadwerkelijk kunnen hebben, en er zeker van zijn dat we elk van hen begrijpen:

  • in rust: Dit is de begintoestand van alle digitale gegevens: in zeer korte termen, dit geeft de gegevens aan die ergens worden opgeslagen zonder te worden gebruikt door en / of doorgegeven aan iemand (inclusief software, derden, mensen, enz.). Van lokale harde schijven aan netwerk aangesloten opslag, van USB pendrives aan mobiele apparaten, van systeemmappen aan database servers, elke fysieke en logische opslagsysteem, eenheid of apparaat is bedoeld om te worden gebruikt om gegevens in rust te bevatten… althans voor een tijdje.
  • in transit: ook bekend als “in beweging”. Dit is ten opzichte van de gegevens die ergens naar ergens anders worden verzonden. Het is vermeldenswaard dat het concept van “gegevensoverdracht” kan plaatsvinden tussen een willekeurig aantal partijen, niet beperkt tot slechts twee (de afzender en een ontvanger): wanneer we bijvoorbeeld een bestand van onze desktop-PC naar onze laptop overbrengen met behulp van ons LAN, voeren we in principe een gegevensoverdracht uit waarbij één partij (vs) betrokken is; omgekeerd, wanneer we een transactie indienen naar een gedistribueerde database, zoals een blockchain, dwingen we een gegevensoverdracht af tussen een onbepaald aantal partijen (de hele blockchain nodes).
  • In gebruik: wanneer de gegevens niet alleen passief worden opgeslagen op een harde schijf of externe opslagmedia, maar wordt verwerkt door een of meer toepassingen – en dus in het proces van wordt gegenereerd, bekeken, bijgewerkt, toegevoegd, gewist, enzovoort – het is bedoeld om te worden “in gebruik”. Het spreekt vanzelf dat gegevens in gebruik vatbaar zijn voor verschillende soorten bedreigingen, afhankelijk van waar het zich in het systeem bevindt en wie er toegang toe heeft en/of het kan gebruiken. Echter, de encryptie van de gegevens in gebruik is nogal moeilijk uit te voeren, omdat het zeer waarschijnlijk verlamde, belemmeren of crashen van de toepassing die daadwerkelijk toegang tot het: om deze reden, de beste manier om de gegevens in gebruik te beschermen is om ervoor te zorgen dat de toepassing zal zorgen voor een dergelijke taak door het aannemen van de meest veilige ontwikkeling en implementatie patronen binnen de broncode.

de som van de drie bovenstaande verklaringen wordt “de drie stadia van digitale Data” genoemd: nu we de kern ervan hebben, zijn we klaar om diep in de encryptie onderwerpen te duiken.

data encryptie in rust

uit de definitie van “in rust” hierboven kunnen we gemakkelijk begrijpen hoe dit soort gegevens meestal in een stabiele staat is: het reist niet binnen het systeem of netwerk, en er wordt niet op gereageerd door een toepassing of derde partij. Het is iets dat een bestemming heeft bereikt, tenminste tijdelijk.

redenen om het te gebruiken

waarom zouden we die gegevens dan versleutelen? Nou, er zijn een aantal goede redenen om dit te doen: laten we eens kijken naar de belangrijkste.

fysieke diefstal

als ons apparaat wordt gestolen, voorkomt de versleuteling in rust dat de dief onmiddellijk toegang heeft tot onze gegevens. Zeker, het kan nog steeds proberen om het te decoderen met behulp van brute-force of andere encryptie-kraken methoden, maar dit is iets dat een redelijke hoeveelheid tijd zal nemen: we moeten zeker in staat zijn om te trekken uit de adeguate tegenmaatregelen voordat dat gebeurt, zoals: het veranderen van de account informatie die hij zou kunnen zien of enigszins gebruiken via bestaande browsers password managers, login cookies, e-mailclients accounts en ga zo maar door; ons apparaat volgen en / of een “Wis alle gegevens” uitgeven met behulp van onze Google-of Apple Remote device management-services, enzovoort.

logische diefstal

als onze PC, website of e-mailaccount wordt gehackt door een kwaadwillende gebruiker of software, zal de versleuteling in rust ervoor zorgen dat de overtreder geen toegang heeft tot onze gegevens-zelfs niet als deze gestolen of gedownload wordt: het is in principe hetzelfde scenario van fysieke diefstal, behalve dat het veel subtieler is omdat de meeste gebruikers (of beheerders) zich er niet eens van bewust zijn.

hier is nog een goede kans om de geweldige woorden van John T. te onthouden. Chambers, voormalig CEO van Cisco, Inc.:

er zijn twee soorten bedrijven: degenen die zijn gehackt, en degenen die niet weten dat ze zijn gehackt.

gezien de huidige staat van het internet en de overdaad aan malwares en meetbare hackpogingen, kan dezelfde uitspraak worden gezegd voor elke eindgebruiker die een webtoestel heeft: 100% guarranteed.

menselijke fouten

laat staan de fysieke en / of logische diefstallen, er zijn een heleboel andere scenario ‘ s waar data-encryptie in rust een redding zou kunnen zijn: bijvoorbeeld, als we onze smartphone verloren (en iemand vindt het); of als we een fout maken bij het toewijzen van machtigingen, het verlenen van toegang aan onbevoegde gebruikers (of klanten) tot bestanden/mappen/gegevens die ze niet moeten kunnen zien; of als we vergeten onze lokale PC of e-mail wachtwoord in het zicht, waardoor iedereen die niet het gevoel dat het respecteren van onze privacy om een kijkje te nemen op onze spullen; en de lijst kan gaan voor een tijdje.

Hoe kan het ons helpen

om dit alles samen te vatten, zouden we onze eerdere vragen met één regel kunnen beantwoorden door te zeggen dat het versleutelen van onze at-rest gegevens ons zou kunnen helpen om beter om te gaan met een mogelijk datalek.

het zal ons niet helpen om dat te voorkomen – wat meestal een taak is voor firewalls, antivirussen, good practices en beveiligingsprotocollen – maar het zal ons zeker de kans (en de tijd) geven om de juiste tegenmaatregelen in te stellen, hopelijk het minimaliseren van de totale schade veroorzaakt door een mogelijk Lek.

Hoe het te implementeren

het Implementeren van een Data-Encryptie-at-rest security protocol kan makkelijk of moeilijk, afhankelijk van de volgende factoren:

  • welke fysieke en logische gegevensbronnen/opslagplaatsen we willen (of hebben) te beschermen: fysieke bronnen zijn: Harde Schijven, NAS-elementen, smartphones, USB-sticks, en dus op, terwijl logische bronnen zijn lokale of externe databases, cloud-gebaseerde activa, gevirtualiseerde apparaten, en ga zo maar door;
  • wie moet toegang hebben tot deze gegevens: mensen (lokale of externe gebruikers of andere derde partijen die met ons verbinden), door mensen aangestuurde software (zoals MS Word) of automatische processen of diensten (zoals een nachtelijke back-uptaak);
  • hoeveel we bereid zijn op te offeren in termen van algemene prestaties en/of het gemak van toegang om de veiligheid te verhogen: kunnen we aan al onze lokale (en externe) gebruikers vragen om deze gegevens te decoderen voordat ze toegang kunnen krijgen? Moeten we een wachtwoord, een fysiek token of een OTP code gebruiken? Kunnen we de encryptie transparant genoeg maken om onze externe gebruikers niet te hinderen en ook om onze software-apps en tools in staat te stellen om te gaan met de versleutelde gegevens wanneer ze nodig hebben om te gaan met het?

gelukkig zijn deze factoren bekend bij de meeste at-rest Encryptie-tools, die zijn ontworpen om onze gegevens te beschermen zonder de algehele functionaliteit van onze omgeving in gevaar te brengen:

  • als we fysieke (of logische) Harde schijven willen versleutelen, kunnen we geweldige softwaretools gebruiken zoals VeraCrypt (100% gratis) of AxCrypt (gratis versie beschikbaar);
  • als we onze USB-pendrives moeten beschermen, kunnen we de bovengenoemde tools gebruiken of een hardware-versleutelde flashdrive aanschaffen die gebruik maakt van vingerafdruk-of wachtwoordgebaseerde ontgrendelingsmechanismen (vanaf 20~30 dollar);
  • als we de gegevens die zijn opgeslagen in een databasemanagementsysteem willen versleutelen, bieden de meeste DBMS die vandaag beschikbaar zijn native encryptie technieken (InnoDB tablespace encryptie voor MySQL en MariaDB, transparante Data encryptie voor MSSQL, enzovoort);
  • als we op zoek zijn naar een manier om onze E-mailberichten veilig op te slaan, kunnen we gemakkelijk een veilige e-mailversleutelingsstandaard gebruiken, zoals S/MIME of PGP (beide zijn gratis): hoewel deze protocollen meestal gerelateerd zijn aan versleuteling tijdens het transport, omdat ze gegevens beschermen die meestal bedoeld zijn om naar externe partijen te worden overgedragen, worden ze in feite vaak gebruikt om een client-side encryptie uit te voeren, wat betekent dat ze de e-mailberichten beschermen terwijl ze nog in rust zijn. Onnodig te zeggen, aangezien deze boodschap hoogstwaarschijnlijk zal worden verzonden, zal onze bestemming(en) ook dezelfde standaard moeten aannemen om ze te kunnen lezen.

data-encryptie in-transit

zoals de naam al aangeeft, moeten gegevens in-transit gezien worden als een transmissiestroom: een goed voorbeeld van data in-transit is een typische webpagina die we van het internet ontvangen wanneer we surfen op het web. Hier is wat er gebeurt onder de motorkap in een notendop:

  1. we sturen een HTTP (of HTTPS) verzoek naar de server die de website host die we bezoeken.
  2. de webserver accepteert ons verzoek, verwerkt het door het vinden van de (statische of dynamische) inhoud waar we om gevraagd hebben en stuurt het vervolgens naar ons als een HTTP (of HTTPS) antwoord via een bepaalde tcp-poort (meestal 80 voor HTTP en 443 voor HTTPS).
  3. onze client, meestal een webbrowser zoals Google Chrome, Firefox of Edge, ontvangt het HTTP (s) – antwoord, slaat het op in de interne cache en toont het aan ons.

zoals we kunnen zien, is er duidelijk een datatransmissie gaande tussen de server en de client: tijdens die trasmissie worden de gevraagde gegevens (de HTML-code van de webpagina) een stroom die door minstens vijf verschillende toestanden gaat:

  1. het begint bij-rest (serveropslag),
  2. verandert dan naar in-use (webservergeheugen),
  3. vervolgens naar in-transit (gebruikmakend van het HyperText Transfer Protocol op een bepaalde TCP poort),
  4. dan weer naar in-use (webbrowser),
  5. en tenslotte naar in-rest (client cache).

redenen om het te gebruiken

laten we nu aannemen dat zowel de server als de client een sterk niveau van data-encryptie in rust hebben geïmplementeerd: dit betekent dat de eerste en de vijfde staat intern veilig zijn, omdat elke intrusiepoging tegen versleutelde gegevens zou worden gedaan. Echter, de derde staat – waar de gegevens in-transit – kan worden versleuteld of niet, afhankelijk van het protocol de server en de client daadwerkelijk gebruiken om de gegevens te verzenden.

dit is wat er meestal gebeurt onder de motorkap wanneer het HTTP-protocol wordt gebruikt:

encryptie in-transit en encryptie in-rest-Definitions and Best Practices

zoals we kunnen zien, is het beveiligingsprobleem duidelijk: wanneer de webserver het inkomende verzoek verwerkt en de gevraagde gegevens transparant decodeert, is het kanaal dat wordt gebruikt om het naar de webclient (HTTP) over te brengen niet versleuteld: daarom kan elke overtredende partij die erin slaagt een geschikte aanval uit te voeren (zie hieronder) onmiddellijk toegang hebben tot onze niet-versleutelde gegevens.

Hoe kan het ons helpen

als u nieuwsgierig bent naar welke soort aanvallen kunnen worden gebruikt tegen een niet-versleuteld TCP-gebaseerd transmissieprotocol zoals HTTP, zijn hier een paar bedreigingen waarvan u op de hoogte moet zijn:

  • afluisteren: een netwerk laag aanval die zich richt op het vastleggen van kleine pakketten van het netwerk verzonden door andere computers en het lezen van de gegevens inhoud op zoek naar elk type informatie (Meer info Hier).
  • Man-In-The-Middle: een op knoeien gebaseerde aanval waarbij de aanvaller in het geheim de communicatie tussen twee partijen doorzendt en/of wijzigt om hen te laten geloven dat ze direct met elkaar communiceren (meer info hier).

het implementeren van goede encryptie in-transit protocollen om onze kritische data transfer endpoints te beveiligen zal ons zeker helpen dit soort bedreigingen te voorkomen.

hoe het te implementeren

het implementeren van een effectief versleutelingspatroon tijdens het transport is meestal een kwestie van vasthouden aan een breed bekende reeks aanbevelingen en beste praktijken bij het ontwerpen van de feitelijke gegevensoverdracht: welke protocollen moeten (niet) worden gebruikt, welke software moet (niet) worden aangenomen, enzovoort. Bijvoorbeeld::

  • wanneer het zendapparaat bereikbaar is via de webinterface, mag webverkeer alleen worden verzonden via Secure Sockets Layer (SSL) met behulp van sterke beveiligingsprotocollen zoals Transport Layer Security (TLS): dit geldt voor elke website en / of WAN-bereikbare service, inclusief e-mailservers en dergelijke. Vanaf vandaag, de beste (en gemakkelijkste) manier om TLS-beveiliging te implementeren en implementeren van de encryptie in-transit voor elke website is door het verkrijgen van een SSL/TLS HTTPS-certificaat: die kunnen worden gekocht bij geregistreerde CA autoriteiten (Comodo, GlobalSign, GoDaddy, DigiCert en hun enorme resellers/subsellers lijst) of automatisch gegenereerd door middel van een self-signing proces, zoals we kort uitgelegd in dit bericht. Hoewel zelfondertekende certificaten hetzelfde versleutelingsniveau bieden als hun tegenhangers met een CA-handtekening, zullen ze over het algemeen niet worden vertrouwd door de gebruikers omdat hun browserclients niet in staat zullen zijn om de goede trouw van de identiteit van de uitgever (u) te verifiëren, waarbij uw website wordt gemarkeerd als “niet vertrouwd”: om deze reden moeten ze alleen worden gebruikt op niet-productie (of niet-openbaar toegankelijke) server/services.
  • alle gegevens die via e-mail worden verzonden, moeten worden beveiligd met behulp van cryptografisch sterke e-mailcoderingshulpmiddelen zoals S/MIME of PGP, die we al hebben behandeld toen we spraken over data-encryptie in rust: hoewel deze protocollen hun encryptie uitvoeren op clientniveau (en dus in rust), zijn ze ook geweldig om de asynchrone in-transit flow van een e-mailbericht te beschermen.
  • binaire gegevens moeten worden versleuteld met behulp van de juiste bestandscoderingshulpmiddelen voordat ze aan e-mail worden gekoppeld en/of op een andere manier worden verzonden. De meeste compressieprotocollen, waaronder ZIP, RAR en 7Z, ondersteunen tegenwoordig een behoorlijk niveau van met een wachtwoord beveiligde encryptie: ze gebruiken is vaak een geweldige manier om een extra beveiligingsniveau toe te voegen en tegelijkertijd de grootte van de bijlage te verminderen
  • niet-web-overdracht van tekst en/of binaire gegevens moet ook worden versleuteld via applicatieniveau encryptie, rekening houdend met de volgende scenario ‘ s:
    • als de toepassingsdatabase zich buiten de toepassingsserver bevindt, moet de verbinding tussen de database en de toepassing worden versleuteld met FIPS-compatibele cryptografische algoritmen.
    • wanneer applicatieniveau-encryptie niet beschikbaar is, implementeer dan Netwerk-encryptie zoals IPSec of SSH-tunneling, en/of zorg ervoor dat de overdracht zelf wordt uitgevoerd met geautoriseerde apparaten die werken in beveiligde subnetten met sterke firewallbesturing (VPN en dergelijke).

de volgende tabel toont enkele voorbeelden van de onveilige netwerkprotocollen die je moet vermijden en hun beveiligde tegenhangers die je in plaats daarvan moet gebruiken:

Transfer Type What to avoid (insecure) What to use (secure)
Web Access HTTP HTTPS
E-Mail Servers POP3, SMTP, IMAP POP3S, IMAPS, SMTPS
File Transfer FTP, RCP FTPS, SFTP, SCP, WebDAV over HTTPS
Remote Shell telnet SSH2
Remote Desktop VNC radmin, RDP

End-to-End encryptie

versleuteling tijdens het transport is echt nuttig, maar het heeft een belangrijke beperking: het garandeert niet dat de gegevens worden versleuteld bij het beginpunt en niet worden gedecodeerd totdat het in gebruik is. Met andere woorden, onze gegevens kunnen nog steeds vooraf worden gedateerd door occasionele en/of kwaadaardige afluisteraars, waaronder internetproviders, communicatieserviceproviders en wie toegang heeft tot de cryptografische sleutels die nodig zijn om de gegevens te decoderen tijdens het transport.

het overwinnen van deze beperking is mogelijk dankzij End-to-End encryptie (E2EE), een communicatieparadigma waarbij alleen de communicerende eindpartijen – bijvoorbeeld de gebruikers – de berichten kunnen ontcijferen en dus lezen. End-to-end versleutelde gegevens worden versleuteld voordat ze worden verzonden en blijven versleuteld totdat ze door de eindpartij worden ontvangen.

redenen om het te gebruiken

om beter te begrijpen hoe end-to-end encryptie in transit encryptie superseeds in termen van veerkracht naar afluisteraars, laten we ons de volgende scenario ‘ s voorstellen.

  1. stel dat een derde erin slaagt zijn eigen basiscertificaat op een vertrouwde certificaatautoriteit te plaatsen: een dergelijke actie zou theoretisch kunnen worden uitgevoerd door een staatsacteur, een politiedienst of zelfs een kwaadwillende/corrupte exploitant van een certificaatautoriteit. Iedereen die in staat is om dit te doen, kan met succes een man-in-the-middle aanval op de TLS-verbinding zelf bedienen, het gesprek afluisteren en mogelijk zelfs ermee knoeien. End-to-end versleutelde gegevens zijn native resilient voor dit soort aanvallen, omdat de encryptie niet wordt uitgevoerd op serverniveau.
  2. End-to-end encryptie kan ook het beveiligingsniveau verhogen onder de gebruikersprocessen die door een besturingssysteem worden voortgebracht. Herinner je je de recente CPU gebreken genaamd SPECTRE en MELTDOWN? Beiden stonden een kwaadaardige derde partij (zoals een malafide proces) om geheugengegevens te lezen zonder toestemming om dit te doen. End-to-end encryptie kan een dergelijk scenario te voorkomen, zolang de encryptie wordt uitgevoerd tussen de gebruiker proces (in tegenstelling tot de kernel), waardoor alle niet-versleutelde gegevens worden gezet in het geheugen.

hoe het ons kan helpen

End-to-end encryptie is de meest veilige vorm van communicatie die tegenwoordig kan worden gebruikt, omdat het ervoor zorgt dat alleen u en de persoon waarmee u communiceert kan lezen wat er wordt verzonden, en niemand ertussen, zelfs niet de service die de overdracht tussen peers uitvoert. Verschillende end-to-end encryptie implementaties zijn al effectief op de meeste messaging apps en diensten (met inbegrip van Whatsapp, lijn, Telegram, en dergelijke). In een typische “communicatie-app” – scenario ‘ s worden de berichten beveiligd met een slot, en alleen de afzender en de ontvanger hebben de speciale sleutel die nodig is om ze te ontgrendelen en te lezen: voor extra bescherming wordt elk bericht automatisch verzonden met zijn eigen unieke slot en sleutel.

implementatie

End-to-end encryptie kan worden gebruikt om alles te beschermen: tegen chatberichten, bestanden, foto ‘ s, sensorische gegevens op IoT-apparaten, permanente of tijdelijke gegevens. We kunnen kiezen welke gegevens we end-to-end willen versleutelen. Bijvoorbeeld, we willen misschien goedaardige informatie met betrekking tot een chat-app (zoals tijdstempels) in platte tekst te houden, maar end-to-end versleutelen van de inhoud van het bericht.

  • elke gebruiker heeft een private & publieke sleutel die de software moet genereren op het apparaat van de gebruiker bij het aanmelden of de volgende keer dat ze inloggen.
  • de publieke sleutel van de gebruiker wordt gepubliceerd op een openbare plaats (zoals een op rust gebaseerde sleutelbeheerdienst): dit is vereist voor gebruikers om elkaars publieke sleutels te vinden en gegevens naar elkaar te kunnen versleutelen.
  • de privésleutel van de gebruiker blijft op het apparaat van de gebruiker, beschermd door het eigen sleutelarchief van het besturingssysteem (of andere beveiligde stores).
  • voordat u een chatbericht verzendt of een document deelt, versleutelt de app de inhoud met behulp van de publieke sleutel van de ontvanger (client-side).

conclusie

onze reis door de verschillende encryptie paradigma ‘ s is voltooid: we hopen oprecht dat dit overzicht gebruikers en systeembeheerders zal helpen om hun bewustzijn van de verschillende soorten encryptie die momenteel beschikbaar zijn te vergroten.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.

lg