Hoe onveilig is AES-128-CTR om elk soort gegevens te versleutelen met het Ethereum keystore-bestandsformaat?
Geplaatst op november 18, 2020 door adminIk gebruik het Ethereum keystore-bestandsformaat om andere gegevens zoals platte tekst of JSON te versleutelen.
Hier is een voorbeeld van pseudocode van de implementatie:
MY_PASSWORD = "VeryDifficultPasword432131!@!#%" MY_TEXT = "This is my secret text" iv = randomBytes(16) kdfparams = { dklen: 32, n: 262144, r: 1, p: 8, salt: randomBytes(32) } key = scrypt(MY_PASSWORD, kdfparams) ciphertext = encryptCipheriv("aes-128-ctr", MY_TEXT, key, iv) mac = sha3(key[16:32], ciphertext)
Met deze code kan ik het keystore-bestand genereren dat er als volgt uitziet:
{ "crypto" : { "cipher" : "aes-128-ctr", "cipherparams" : { "iv" : "83dbcc02d8ccb40e466191a123791e0e" }, "ciphertext" : "d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c", "kdf" : "scrypt", "kdfparams" : { "dklen" : 32, "n" : 262144, "r" : 1, "p" : 8, "salt" : "ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19" }, "mac": "102aedfe8c308c735a76295f9908d9b7de40fb1c07f2f71e05de7a0b2f323a12" } }
Dit is het standaardbestand waarin miljoenen dollars aan mensen in Ethers worden opgeslagen.
Vragen:
- Is dit veilig?
- Zo nee, waarom?
- Zo ja, is het ook veilig om platte tekst of JSON (geen hexadecimaal formaat) te versleutelen?
- Is het veilig om een kleinere
kdfparams.n
?
Bewerken: om te verduidelijken waarom ik dit vraag is omdat een andere persoon dit zei:
Dit is helemaal niet veilig. Deze implementatie bevat veel basisfouten. Een voorbeeld is het gebruik van een onveilige generator voor willekeurige getallen, die de beveiliging van de codering volledig vernietigt. Een andere is het gebruik van AES- 128-CTR zonder authenticatie.
Reacties
- Definieer eerst ” secure ” . Maar volgens een redelijke definitie daarvan, met een wachtwoord in dezelfde klasse als ‘ 1234 ‘, en platte tekst die groot en redundant is, niets dat bruikbaar is, is veilig.
- Veilig in termen van heel erg moeilijk te breken, zelfs als dat zo is een goede cryptograaf.L laat me bewerken om duidelijk te maken dat dit een erg sterk wachtwoord zou zijn.
- Definieer nu ” break ” . Is dat het vinden van het originele wachtwoord? Raad de leesbare tekst uit één cijfertekst? Raad je een deel van de leesbare tekst van veel cijfertekst die dat sommige delen? Eén leesbare tekst raden uit vele cijferteksten en alle andere platte tekst? Kunnen we hulp krijgen van een uitvoerbaar bestand dat op dezelfde machine draait (en zo ja, welke CPU met welke microcode-patch? Wordt AES-NI gebruikt?). Kunnen we EMI als nevenkanaal gebruiken? Een keylogger, hardware of sotfare? Inderdaad, wat is ‘ is de implementatie van randomBytes, wat een invloed heeft?
- Je kunt deze vraag niet beantwoorden door naar psuedocode te kijken. De daadwerkelijke implementatie kan allerlei kwetsbaarheden en zijkanalen bevatten. Beveiliging is ook geen binair bestand, het ‘ is een kwestie van hoever u ‘ bereid bent om u te beschermen tegen steeds meer exotische aanvallen .
- @ fgrieu sorry, de enige vraag die ik kan beantwoorden is: nodejs.org / api / … @EllaRose Ik neem aan dat de bibliotheken die ik gebruik geen kwetsbaarheden hebben. Dus mijn pseudocode hierboven is slechts een implementatie van die bibliothekenfuncties, zoals randomBytes.
Answer
Het ergste puur cryptografische zwakte is het wachtwoord (1). De ergste (en veel erger) praktische zwakheden zijn waarschijnlijk de implementatie (6) (7), en die (4) (5) die cryptografen afdoen als buiten de scope van encryptie (het enige gestelde doel van de vraag).
Kandidaten voor zwakke punten, van cryptografisch (maar nog te overwegen) tot implementatie:
- Het wachtwoord: het is moeilijk om een wachtwoord te onthouden met meer dan 48 bits entropie ( dat “is ongeveer gelijk aan een 16-cijferig nummer, zoals 3141592653589793 of 2718281828459045, en meer dan voorzien door de verplichte XKCD ). Met N = 262144 = 2 18 , r = 1, p = 8 = 2 3 , worden minimaal 18 + 3 + 1 = 22 bits gekocht (zie this ) vergeleken met een gewone SHA-256-hash gevolgd door AES-128, denk ik ongeveer 32 bits sterker, dus de sleutel kan ongeveer 80-bits goed zijn, wat niet geheel onbreekbaar door brute kracht, maar nog steeds redelijk veilig.
- AES-128: dit heeft een 128-bits sleutel, geen puur cryptoanalytische aanval beter dan brute kracht, en is dus veel beter dan het wachtwoord.
- CTR-modus: met het 128-bits blok van AES is de enige manier waarop key-stream hergebruik kan optreden een slecht willekeurig getal generator voor de IV (zie 6)
- De grootte van de platte tekst kan moeiteloos worden afgeleid uit de grootte van de cijfertekst. Dit is expliciet geen een theoretische zwakte van codering, aangezien lengte is uitgesloten van wat een cijfer zou moeten verbergen over leesbare tekst. Dat kan echter een praktisch zwak punt zijn. Stel dat analyse van versleutelde tekst concludeert dat het 17267095423 octetten; en er bestaat ergens in de aanklager een dossier met precies die grootte, aantoonbaar dateert van vóór het doorzoeken en in beslag nemen van de cijfertekst, en dat louter opsluiting illegaal is.
- Gebrek aan detectie van (opzettelijke of onbedoelde) cijfertekstwijzigingen, wat overeenkomt met voorspelbare verandering in de leesbare tekst: nogmaals, dit is expliciet geen een theoretische zwakte van codering, maar kan wel enkele aanvallen toestaan als de tegenstander de cijfertekst kan wijzigen (voorbeeld: als de leesbare tekst een uitvoerbaar bestand is of een pdf met een bekende breuk, kan dat het veranderen van wat het uitvoerbare bestand met iets doet, of ervoor zorgen dat de pdf als ongeveer alles wordt weergegeven). Geverifieerde versleuteling ( AES-GCM ..) lost dat op.
- Willekeurige nummergenerator: als dit slecht is, of erger, blijft het min of meer vastlopen (verplicht XKCD en Dilbert die maar al te vaak naar de werkelijkheid gaan), waardoor in veel scenarios platte tekst kan worden hersteld, inclusief het herhaaldelijk coderen van verschillende Engelse tekst- of e-mailadressen met hetzelfde wachtwoord.
- Een zijkanaal, dat wil zeggen in grote lijnen het spreken van onvoorziene of regelrechte lekken van informatie in de implementatie- of gebruikscontext. Er zijn er zoveel:
- Wachtwoordherstel van de wachtwoordhouder door misbruik te maken van een procedurele fout (wachtwoord op een postit-notitie, hoofdwachtwoordlijst), rubberen slang-cryptanalyse (verplicht XKCD ), juridische varianten (waarbij gebruik wordt gemaakt van uitdrukkingen op de melodie van minachting van de rechtbank ), omkoping, chemische impregnering.
- Wachtwoordherstel door schoudersurfen , keylogger (software of hardware), camera, microfoon (een goede audio-opname van het geluid van toetsen bij het invoeren van een wachtwoord lekt veel informatie over het wachtwoord, vooral wanneer deze wordt gecorreleerd met bekende toetsenbordinvoer door dezelfde operator onder dezelfde omstandigheden).
- Rechtstreeks compromis van platte tekst zoals weergegeven op het scherm (met TEMPEST varianten daarvan), afgedrukt, terwijl ze naar een printer worden verzonden of op afstand worden benaderd door een netwerk, of gewoon tijdelijk worden opgeslagen.
- Rechtstreeks compromis van het besturingssysteem van de mach het doen van codering of decodering (tijdelijke root-toegang is voldoende, betekent in 7.7 een spel voor de aanvaller).
- Cryptanalytisch zijkanaal op afstand, inclusief DPA en elektromagnetische variant DEMA, en hypothetisch timing als de machine die de codering / decodering uitvoert, wordt benaderd door een netwerk en geen AES-instructies .
- Cryptanalytisch zijkanaal van een proces dat op dezelfde hardware draait (inclusief een andere VM), inclusief cache-gebaseerde targeting voor AES wanneer AES niet wordt gebruikt instructies, of meer algemene instructies (Meltdown, Spectre) die tegenwoordig allemaal razernij zijn.
- Exploitatie van verschillende softwarefouten; dat is enorm.
Reacties
- Het zou handiger zijn als ik het wachtwoord hashen vóór de versleuteling? Zoals het gebruik van sha of md5?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: het hash-wachtwoord voor invoer in scrypt verandert niet veel de moeilijkheid van een aanval op het wachtwoord ( punt 1). Om dit te verbeteren heeft men een beter wachtwoord nodig, een betere parametrisering voor scrypt, of een beter op wachtwoorden gebaseerd sleutelafleidingsschema (Argon? Balloon?)
Antwoord
Het belangrijkste beveiligingselement dat kan worden aangevallen in het bovenstaande schema is – natuurlijk – het wachtwoord. Nu is het zout belangrijk om regenboogtafelaanvallen te vermijden, maar verder is het voegt niet zoveel beveiliging toe. Als het salt en het wachtwoord redelijk uniek zijn, is de sleutel ook uniek. In dat geval is de IV niet dat belangrijk.
Dus hoewel het gebruik van een onveilige generator voor willekeurige getallen slecht is, heeft het waarschijnlijk niet zoveel invloed op de praktische beveiliging. , geeft het wel aan dat er inderdaad slechte praktijken zijn geïmplementeerd. Wat als de wachtwoordzin werd gegenereerd met dezelfde onveilige willekeurige generator? En als er andere implementatiefouten aan de oppervlakte komen?
Het gebruik van niet-geverifieerde cijfertekst is een groter probleem, aangezien het zou de tegenstander in staat stellen om de leesbare tekst voor elk bit te wijzigen. De tegenstander kan eenvoudig elk cijfertekstbit omkeren en de platte tekstbit op dezelfde positie zal ook omdraaien. Dit zou betekenen dat u een fout of een probleem zou krijgen bij het gebruik van de portefeuille. De vertrouwelijkheid van de inhoud van de portemonnee gaat waarschijnlijk niet verloren, maar het gebruik van geverifieerde versleuteling is zeker de beste praktijk.
Opmerkingen
- Bedankt! Kunt u het uitleggen? nauwelijks hoe ik geauthenticeerde cijfertekst met deze modus kan krijgen? Ik ga th bewerken e voorbeelden hierboven omdat ik denk dat het verband houdt met de originele mac-eigenschap die ik uit het originele keystore-bestand heb verwijderd.
- De CTR-modus is de onderliggende modus van CCM, GCM, EAX, SIV en een hele reeks andere geverifieerde cijfers. Een combinatie van CTR-modus met een (H) MAC kan echter zeker ook veilig zijn.Beide produceren een authenticatietag met ongeveer dezelfde grootte / beveiliging. CCM en EAX zijn niet veel meer dan specifieke combinaties van CTR en een MAC waarbij dezelfde sleutel kan worden gebruikt voor de code en de MAC.
- Merk op dat ik ‘ ve beantwoordde deze vraag naar mijn beste kunnen, met behulp van algemene kennis van cijfers (niet zozeer Ethereum). Ella Rose heeft gelijk dat we de veiligheid van het systeem niet kunnen concluderen uit de informatie die ons in de vraag is gegeven. Dus ik ‘ heb me uitsluitend geconcentreerd op het gebruik van CTR.
- Nou, het toeval lijkt – uiteindelijk – te vertrouwen op het willekeurige systeem. Vaak zijn willekeurige systeembronnen relatief veilig en wordt de term CSPRNG inderdaad door de bron genoemd. Dus de bewering dat het niet willekeurig is, is onjuist, tenzij het willekeurige systeem niet goed is geïmplementeerd of niet goed is geseed.
- Het rechtstreeks aanmaken van een MAC van SHA-3 wordt niet aanbevolen; in plaats daarvan had KMAC moeten worden gebruikt (het is waarschijnlijk was gewoon niet ‘ t opgegeven). Maar ik kan geen situatie bedenken waarin het gebruik van de aaneenschakeling van de sleutel en de cijfertekst ooit een probleem zou vormen.
Geef een reactie