Waarom over cryptografie? Ik heb er zelf nogal oppervlakkige kennis van. Ja, ik heb het klassieke werk gelezen , maar dat is al een hele tijd geleden; ja, ik begrijp het verschil tussen symmetrische en asymmetrische encryptie, ik begrijp wat elliptische krommen zijn, maar dat is het ook. Bovendien zorgt de bestaande cryptografische bibliotheken, met hun leuke gewoonte om de volledige naam van het algoritme in de naam van elke functie op te nemen en talloze zichtbaar inititalisatoren te hebben, voor een enorme frustratie bij mij als programmeur.
Dus waarom? Waarschijnlijk omdat ik, bij het lezen van de huidige wave van publicaties over gegevensbescherming, vertrouwelijke informatie, enz., het gevoel heb dat we ergens niet goed bezig zijn, of specifieker, we proberen met technische middelen (cryptografie) sociale problemen op te lossen. Laten we daarover praten, ik beloof geen monumentale onthullingen of concrete voorstellen, het zijn gewoon gedachten.
Een beetje geschiedenis, heel weinig
In 1976 werd in de VS een federale standaard voor symmetrische encryptie-algoritmen aangenomen ā DES. Dit was het eerste openbare en gestandaardiseerde cryptografische algoritme, ontwikkeld als reactie op de groeiende vraag van bedrijven naar gegevensbescherming.
Een kurioos voorval
Het algoritme werd per ongeluk gepubliceerd. Het was geoptimaliseerd voor hardware-implementatie en werd als te complex en inefficiƫnt voor software beschouwd. Echter, de wet van Moore stelde snel alles op zijn plaats.
Je zou denken ā dat is het einde van het verhaal, neem het, versleutel, ontsleutel, en vergroot de sleutel indien nodig. Misschien weet je heel goed dat de Amerikanen er achterdeurtjes in hebben achtergelaten, dan is er een Russische tegenhanger voor jou ā , dat je echter waarschijnlijk nog minder vertrouwt. Gebruik dan beide, Ć©Ć©n bovenop de ander. Als je gelooft dat de FBI en de FSB voor jou hebben samengewerkt en hun achterdeurtjes hebben uitgewisseld, dan heb ik goed nieuws voor je ā je bent geen paranoĆÆde, je hebt gewoon een banale grootheidswaanzin.
Hoe werkt symmetrische encryptie? Beide deelnemers kennen dezelfde sleutel, ook wel het wachtwoord, en wat is versleuteld, kan ook weer door hen worden ontsleuteld. Deze methode werkt prima voor spionnen, maar is volkomen ongeschikt voor het moderne internet, omdat deze sleutel vooraf aan elk van de gesprekspartners moet worden doorgegeven. Een tijdlang, terwijl slechts een relatief klein aantal bedrijven hun gegevens beschermde in communicatie met vooraf bekende partners, werd het probleem opgelost met behulp van koeriers en beveiligde post, maar toen werd het internet massaal en ontstond er een
asymmetrische cryptografie
waarbij twee sleutels betrokken zijn: een publieke, die niet geheim wordt gehouden en aan iedereen wordt meegedeeld; en een private, waarvan alleen de eigenaar op de hoogte is. Wat met de publieke sleutel is versleuteld, kan alleen met de private sleutel worden ontsleuteld, en vice versa. Zo kan iedereen de publieke sleutel van de ontvanger leren kennen en hem een bericht sturen, dat alleen de ontvanger kan lezen. Lijkt het probleem opgelost?
Maar Het internet werkt echter anders, hiermee rijst het probleem van authenticatie en, vooral, initiƫle authenticatie, en in zekere zin het tegenovergestelde probleem van anonimiteit. Kort samengevat, hoe kan ik er zeker van zijn dat degene met wie ik praat, werkelijk degene is met wie ik had willen praten? En dat de publieke sleutel die ik gebruik, daadwerkelijk toebehoort aan degene met wie ik had willen praten? Vooral als ik deze persoon voor het eerst spreek? En hoe kan ik vertrouwen bij de partner wekken, terwijl ik tegelijkertijd mijn anonimiteit behoud? Hier, als je goed kijkt, kun je een innerlijke tegenstrijdigheid opmerken.
Laten we in grote lijnen bekijken welke interactieschema's tussen deelnemers bestaan en in de praktijk worden toegepast:
- server - server (of business - business, in deze context is dit hetzelfde): dit is het eenvoudigste klassieke schema, waarvoor symmetrische cryptografie voldoende is, de deelnemers weten alles van elkaar, inclusief netwerkcontacten. Let op: er is hier helemaal geen sprake van anonimiteit, en bovendien is het aantal deelnemers strikt beperkt tot twee. Dit is dus een bijna perfect schema voor een zeer beperkt aantal communicatie-uitwisseling en in het algemeen duidelijk weinig toepasbaar.
- server ā anoniem (of business ā klant): hier is er sprake van een zekere asymmetrie, die succesvol wordt bediend door asymmetrische cryptografie. Het belangrijkste punt hier is het ontbreken van klantauthenticatie; voor de server is het onbelangrijk met wie hij gegevens uitwisselt; als dit ooit nodig blijkt te zijn, voert de server secundaire authenticatie door middel van een vooraf overeengekomen wachtwoord, en dan komt alles terug op de vorige situatie. Aan de andere kant is het voor de klant uiterst belangrijk om de server te authentiseren; hij wil er zeker van zijn dat zijn gegevens precies bij de juiste persoon komen, deze kant is in de praktijk gebaseerd op een certificatiesysteem. Over het geheel genomen wordt zo'n schema behoorlijk handig en transparant gedekt door het https:// protocol, maar er ontstaan een paar interessante punten op het snijvlak van cryptografie en sociologie.
- vertrouwen in de server: zelfs als ik bepaalde informatie op een absoluut veilige manier naar het noorden heb gestuurd, hebben daar technisch gezien derden toegang toe. Dit probleem valt volledig buiten de verantwoordelijkheden van encryptie, maar ik vraag je om dit punt te onthouden; het zal later nog opduiken.
- vertrouwen in het servercertificaat: de hiƫrarchie van certificaten is gebaseerd op het feit dat er een bepaalde wortel- certificaat is dat absoluut vertrouwen waardig is. Technisch gezien kan een voldoende invloedrijke aanvaller [, beschouw het woord aanvaller als een technische term, niet als laster of belediging van de huidige autoriteit] het certificaat van elk lager niveau vervalsen, maar men gaat ervan uit dat het certificeringssysteem voor iedereen in gelijke mate nodig is, d.w.z. deze certificeringsinstantie zal onmiddellijk worden geƫxcommuniceerd en al zijn certificaten ingetrokken. Dat is zoals het is, maar let op dat het systeem niet is gebaseerd op technische middelen, maar op een soort sociaal contract. Overigens, over de apocalyptische toekomst van de RuNet heeft iemand het mogelijke isolement van het Russische rootcertificaat en de gevolgen daarvan geanalyseerd? Als iemand hierover heeft gelezen of geschreven, stuur me dan links, ik zal ze toevoegen; ik vind het een interessant onderwerp. Trouwens, over het hete onderwerpIn de context van de verwachte apocalyptische omslag van de RuNet, heeft iemand de mogelijke isolement van het Russische rootcertificaat en de gevolgen ervan geanalyseerd? Als iemand hier iets over heeft gelezen of geschreven, stuur alsjeblieft links, ik zal ze toevoegen; ik vind het een interessant onderwerp.
- Indirect de-anonymization on the server: this is also a sensitive topic, even if the server lacks formal registration/authentication, there are many ways to gather information about the client and ultimately identify them. It seems to me that the root of the problem lies in the existing HTTP protocol and similar ones, which could not have foreseen such chaos; and it would have been quite possible to create a parallel protocol without these flaws. However, this contradicts all current monetization practices and is therefore unlikely. Still, it's interesting, has anyone tried?
- Anonymous ā anonymous: two people meet online, (option ā just met), (option ā not two but two thousand), and want to chat about their own matters, but in such a way that Big Brother does not hear (option ā mom doesn't find out, everyone has their own priorities). You may hear irony in my voice, well that's because it is indeed there. Let's apply Schneier's postulate to the task (any algorithm can be broken if enough resources are invested, meaning money and time). From that standpoint, infiltrating such a group through social methods poses no difficulty, let alone the financial aspect, meaning the cryptographic strength of the algorithm is zero with the most sophisticated encryption methods.
However, in this case, we have a second bastion ā anonymity, and we place all our hopes on it, let everyone know us, but no one can find us. However, with the most modern technical protection methods, do you seriously believe you have a chance? I remind you that I am now only talking about anonymization; we seem to have convincingly dealt with data protection already. For clarity, let's agree that if your name of home address of IP address is known, the cover is completely blown.
By the way about IP, here the aforementioned rises up in full force trust in the server, hij weet vast uw ip zonder enige twijfel. En alles speelt tegen u ā van gewoon menselijk nieuwsgierigheid en ijdelheid tot bedrijfsbeleid en dezelfde monetisatie. Vergeet niet dat VPS en VPN ook servers zijn; theoretici van cryptografie geven niet veel om deze afkortingen; ja, en de jurisdictie van de server doet er, bij grote nood, niet toe. Ook end-to-end encryptie valt hieronder ā het klinkt mooi en degelijk, maar je moet toch de server op zijn woord geloven.
Wat is eigenlijk de rol van de server in zoān messenger? Ten eerste, triviaal, de postbode, als de ontvanger niet thuis is, zal hij later nog een keer langs komen. Maar veel belangrijker is dit: het is een ontmoetingspunt, je kunt de brief niet direct naar de ontvanger sturen, je stuurt deze naar de server voor verdere verzending. En het belangrijkste is, de server voert de noodzakelijke authenticatie, waarmee hij aan iedereen bevestigt dat jij jij bent, en aan jou dat je gesprekspartner daadwerkelijk degene is die je nodig hebt. En dat doet hij met behulp van jouw telefoon.
Vind je het niet vreemd dat je messenger zoveel van je weet? Nee, nee, we geloven hem natuurlijk (en trouwens ook onze telefoon, eh), maar cryptografen verzekeren dat dit onterecht is, dat je niemand moet geloven.
Niet overtuigd? Maar er is ook nog sociale engineering; als je in een groep met honderd gesprekspartners zit, moet je er gewoon van uitgaan dat 50% van hen vijanden is, 49% ofwel ijdel, ofwel dom, of gewoon onvoorzichtig. En ook die ene procent, hoe goed je ook bent in informatiebeveiligingsmethoden, zul je waarschijnlijk niet op kunnen tegen een goede psycholoog in de chat.
De enige beschermingsstrategie lijkt te zijn om je te verstoppen tussen miljoenen soortgelijke groepen, maar dat gaat niet over ons, weer over een paar spionnen-terroristen, voor wie netwerken, roem of monetisatie er niet toe doen.
Ik denk dat ik op de een of andere manier mijn ernstige gedachten over gegevensbescherming in het moderne maatschappelijk model heb onderbouwd (nee, niet bewezen, alleen onderbouwd). De conclusies zijn simpel maar treurig ā we moeten niet rekenen op meer hulp van gegevensversleuteling dan we al hebben; cryptografie heeft alles gedaan wat mogelijk was, en dat niet slecht, maar ons internetmodel staat volledig haaks op onze streven naar privacy en ondermijnt al onze inspanningen. Ik ben eigenlijk geen pessimist en zou nu graag iets positiefs willen zeggen, maar ik weet gewoon niet wat.
Probeer het volgende gedeelte te bekijken, maar ik waarschuw je ā daar zijn het volledig roze onwetenschappelijke fantasieĆ«n, die misschien iemand kunnen hoop geven, of op zijn minst iemand kunnen amuseren.
Is er Ć¼berhaupt iets wat we kunnen doen?
Nou, bijvoorbeeld hierover nadenken, liefst met een open geest en vooroordelen opzijschuivend. Laten we bijvoorbeeld tijdelijk volledig anonymousiteit opgeven, hoe verschrikkelijk dat ook klinkt. Laten we elke persoon vanaf de geboorte een unieke persoonlijke openbare sleutel geven, en natuurlijk de bijbehorende privĆ©-sleutel. Schreeuw niet tegen me en stamp niet met je voeten, in een ideale wereld is dit uiterst praktisch ā hier hebben we zowel een paspoort, een belastingnummer, als zelfs een telefoonnummer in Ć©Ć©n pakket. Bovendien, als we daar een individuele certificaat aan toevoegen, krijgen we een universele authenticator/login; en bovendien ā een pocket-notaris met de mogelijkheid om documenten te bekrachtigen. We kunnen het systeem gelaagd maken ā alleen de openbare sleutel en het certificaat zijn openbaar, voor vrienden (de lijst met sleutels is hier inbegrepen) kan ook het telefoonnummer en andere items die aan vrienden zijn toevertrouwd toegankelijk zijn, er kunnen nog diepere niveaus zijn, maar dat veronderstelt al onnodig vertrouwen in de server.
Met deze opzet wordt de privacy van verzonden informatie automatisch gewaarborgd (hoewel, aan de andere kant, waarom zou dat nodig zijn in een ideale wereld?), Alice schrijft iets naar Bob, maar niemand zal het ooit lezen behalve Bob zelf. Alle messengers krijgen automatisch end-to-end encryptie, hun rol beperkt zich tot postbussen en er kunnen geen klachten over de inhoud zijn. Bovendien worden servers verwisselbaar; je kunt via de ene server verzenden, of via de andere, of zelfs via een keten van servers, zoals met e-mail. Je kunt zelfs rechtstreeks naar de ontvanger sturen, als je zijn IP kent, zonder enige tussenpersoon. Is dat niet geweldig? Het is alleen jammer dat we in deze prachtige tijd niet zullen leven ā noch ik, noch jijĀ© Tja, daar ben ik weer met iets treurigs.
En waar moeten we dit allemaal opslaan? Nou, op het eerste gezicht een open hiĆ«rarchisch systeem creĆ«ren, iets zoals het huidige DNS, maar dan krachtiger en uitgebreider. Om de beheerders van root DNS servers niet te belasten met toevoegingen en wijzigingen, zou je vrije registratie kunnen invoeren, waarbij de enige noodzakelijke controle is op uniciteit. Zoals >> " Hallo, wij zijn met vijf personen, de familie Ivanov. Hier zijn onze namen/nicks, hier zijn de publieke sleutels. Als iemand vraagt, stuur ze dan alstublieft naar ons door. En hier is ook een lijst van vijftienhonderd oma's uit onze buurt met hun sleutels; als er naar hen wordt gevraagd, stuur ze dan ook alsjeblieft naar ons.Ā«
We moeten de installatie en configuratie van zo'n thuisserver heel eenvoudig en gebruiksvriendelijk maken, zodat iedereen het kan begrijpen als ze dat willen; bovendien zal niemand onnodig officiƫle staatsservers belasten.
Stop!, wat heeft de staat daar dan mee te maken?
En nu kunnen we voorzichtig onze anonimiteit herstellen. Als iedereen zichzelf een persoonlijke sleutel kan genereren en deze kan bevestigen met een persoonlijke certificaat en een CA-server van een lager niveau kan opzetten, of bij de buurman kan vragen, of op een openbare server kan gaan, waarom al die formaliteit? En dan is er geen enkele reden om aan een echt persoon vast te zitten, volledige privacy, beveiliging en anonimiteit. Het is voldoende dat er aan het begin van de hiĆ«rarchie iemand staat die het vertrouwen waard is, nou, we geloven toch in TM of Letās Encrypt, en bekende openbare DNSāen hebben ook nog niemand de woestijn ingestuurd. Van de bureaucratie lijken er ook geen klachten te zijn, dat wil zeggen, er zullen natuurlijk klachten zijn, maar waar is dat precies voor nodig?
Misschien zal zo'n systeem, of iets dergelijks, ooit worden opgezet. En natuurlijk kunnen we niet op iemand anders rekenen dan op onszelf, geen enkel land dat ik ken zal zo'n systeem opzetten. Gelukkig tonen bestaande diensten zoals Telegram, i2p, Tor, en waarschijnlijk ben ik nog iemand vergeten, aan dat er niets fundamenteel onmogelijks is. Dit is ons netwerk, en we moeten het verbeteren als we niet tevreden zijn met de huidige situatie.
Brrr, ik ben per ongeluk op een verhitte noot geƫindigd. Eigenlijk hou ik daar niet zo van, sarcasme ligt dichter bij me.
PS: dit zijn allemaal natuurlijk roze luchtballonnen en meisjesdromen
PPS: maar als iemand het in zijn hoofd krijgt om het te proberen - reserveer dan mijn nickname alsjeblieft, ik ben eraan gewend geraakt
PPPS: maar de uitvoering lijkt heel eenvoudig te zijn, trouwens
Bron: habr.com
