Portemonneebeveiliging: de 'niet-bewarende' denkfout

De vaak aangehaalde uitdrukking "niet uw sleutels, niet uw crypto" geeft de puristische filosofie van cryptografisch sleutelbeheer weer. In dit portemonnee-beveiligingsmodel heeft alleen een individu (of een groep via "multisig") directe en uitsluitende controle over hun eigen privésleutels - en heeft daarom het echte eigendom van hun crypto-activa. Crypto-wallets die zich aan deze harde aanpak houden, worden 'non-custodial' genoemd, wat betekent dat externe partijen geen toegang hebben tot sleutels.

Behalve, niet zo snel. De situatie is niet zo eenvoudig. Een aantal spraakmakende "niet-bewarende" portemonnee-hacks - waaronder de Helling portemonnee hack dat in augustus meer dan 8,000 accounts in gevaar bracht, Trinity portemonnee hack die in 2 meer dan $ 2020 miljoen aan IOTA-tokens verloor, de Pariteit portemonnee hack waardoor een aanvaller in 150,000 2017 ETH kon stelen, plus ontdekkingen van verschillende hardware wallet kwetsbaarheden, en andere incidenten – ondermijnt het conventionele onderscheid tussen bewarende en niet-bewarende portemonnees. In veel van deze gevallen ontdekten slachtoffers die dachten dat ze een niet-bewarende portemonnee gebruikten, dat aanvallers hun felbegeerde sleutels konden kapen. Een contradictie, niet?

Het verhaal is inderdaad complexer dan een slogan kan vatten. Non-custodial wallets geven gebruikers niet echt volledige controle over hun sleutels. Dat komt omdat portemonnees meestal zijn: gemaakt door, en geëxploiteerd via, de software of hardware van iemand anders. Gebruikers stellen voortdurend hun vertrouwen in andere mensen, producten en computerprogramma's. Ze accepteren het gebruik van blockchain-opdrachtregelinterfaces, portemonneesoftware en -apparaten, gecentraliseerde platforms, slimme contractcode, gedecentraliseerde applicaties en alle verschillende portemonnees verbindingsintegraties ertussen. Elk contactpunt voegt risico toe; de som van al deze in elkaar grijpende delen verbrijzelt de illusie van de niet-bewarende portemonnee.

Bewaring is in feite niet-binair. Wat op het eerste gezicht niet tot vrijheidsbeneming lijkt, kan in feite veel elementen van vrijheidsbeneming inhouden waarvan de betrouwbaarheid door mensen vaak als vanzelfsprekend wordt beschouwd. De traditionele dichotomie – vrijheidsbeneming versus niet-vrijheidsbeneming – is een valse. 

In plaats daarvan is het beter om wallets wat genuanceerder te bekijken. De belangrijkste vragen die u moet stellen, zijn: hoe groot kan ik een aanvalsoppervlak accepteren en hoeveel verantwoordelijkheden ben ik bereid op mij te nemen in mijn zoektocht om het vertrouwen in derden weg te nemen? Over het algemeen kan sleutelbeheer - de basis van portemonnee-beveiliging - worden onderverdeeld in drie gebieden, die elk unieke mogelijkheden voor blootstelling hebben. De subcategorieën zijn als volgt:

1. Sleutelgeneratie (cryptografische sleutels maken)

2. Sleutelopslag (beveiligde sleutels in rust)

3. Sleutelgebruik (sleutels aan het werk)

Dit overzicht is bedoeld om web3-gebruikers een beter inzicht te geven in de fijne kneepjes van het beveiligen van hun activa door middel van de bovenstaande rubriek. Verder willen we ingenieurs helpen bij het identificeren en versterken van frequente faalpunten in de ontwikkeling van portefeuilles. We hopen dat het toepassen van deze gids - afkomstig van onze jarenlange gecombineerde ervaring met het bouwen van crypto- en beveiligingssystemen voor Docker, Anchorage, Facebook en a16z crypto - mensen zal helpen beveiligingsproblemen te voorkomen, of ze nu interactie hebben met, deelnemen aan of web3-technologie bouwen.

Hieronder bespreken we gemeenschappelijke kenmerken en valkuilen van crypto-portemonneebeveiligings- en bewaringsplatforms zoals ze nu bestaan. We behandelen ook gebieden die volgens ons de meeste aandacht en ontwikkeling vereisen in de komende maanden en jaren om de veiligheid van de web3-ervaringen van gebruikers te verbeteren.

Portefeuillebeveiliging voor het genereren van sleutels

Elke discussie over portemonnee-beveiliging moet beginnen met het genereren van sleutels, het proces van het maken van cryptografische sleutels. Of de portemonnee nu als bewaarnemer of niet-bewaarplaats wordt beschouwd, de beveiligingseigenschappen van de stap voor het genereren van de sleutel zijn van het grootste belang voor de veiligheid van de sleutels daarna. Tijdens het genereren van sleutels zijn er drie overkoepelende zorgen om in gedachten te houden: het gebruik van betrouwbare code, het correct implementeren van de code en het veilig omgaan met de uitvoer.

Als u geen crypto-expert bent, kan het moeilijk zijn om te verifiëren dat alle volgende factoren volgens het boekje worden gedaan. Controleer of u toegang hebt tot een vertrouwd auditrapport, dat sommige portemonnee-aanbieders publiceren op hun officiële websites of Github-repositories. In plaats daarvan, doe je eigen onderzoek om te proberen te bepalen of er een gerenommeerd bedrijf achter de portemonnee zit. Als informatie schaars is, kan aanzienlijke activiteit van gebruikers en ontwikkelaars de volgende indicator van reputatie zijn.

Volg deze richtlijnen om uw risicoblootstelling te verminderen. Als een portemonnee de onderstaande controles niet doorstaat, ren dan weg!

• Gebruik portefeuilles die hun eigen crypto niet rollen

Cryptografen hebben een gezegde: "rol niet je eigen crypto". De essentie is vergelijkbaar met het adagium "vind het wiel niet opnieuw uit". Het wiel is prima zoals het is en elke poging om er een helemaal opnieuw op te bouwen zal waarschijnlijk resulteren in een slechter product. Hetzelfde geldt voor crypto, een wetenschap die moeilijk precies goed te krijgen is. De code waaruit een portemonnee bestaat, moet de reputatie hebben goed te werken. Kiezen voor slecht geschreven software – of proberen een eigen alternatief te ontwikkelen de novo – kan leiden tot ongelukken, zoals het uitlekken van sleutels of het onthullen van geheime informatie aan onbevoegden. Dit is wat er achter een recent misbruikte kwetsbaarheid zat in Profanity's ijdelheid adres tool. Voor alles moet het duidelijk zijn dat de portemonnee in kwestie een gecontroleerde en gerenommeerde sleutelgeneratiebibliotheek en -proces gebruikt.

• Gebruik portemonnees die twee keer meten en keer op keer snijden

Zelfs als de code gebruikmaakt van gerenommeerde cryptografiebibliotheken, moet deze nog steeds correct worden geïntegreerd. Doorgelichte software zal doorgaans standaard de juiste parameters instellen, maar er kunnen hiaten zijn in de uitvoering. Er is bijvoorbeeld een sterke bron van entropie of een dosis wiskundige willekeur nodig om de te genereren sleutels onvoorspelbaar en dus veiliger te maken. Voor bepaalde sleutelgeneratieprocessen, zoals voor veel Multi-Party Computation (MPC) -algoritmen, waarin veel afzonderlijke sleutels - of shards, fragmenten van sleutels - moeten worden gegenereerd en gecoördineerd, moet de portemonnee het precieze protocol volgen zoals gespecificeerd door de algoritme. Het algoritme kan ook meerdere berekeningsrondes vereisen, evenals verfrissende sleutels, die de portemonnee correct moet integreren om de veiligheid van het geld te behouden.

• Gebruik een portemonnee die geheimen kan bewaren

De laatste fase van het sleutelgeneratieproces omvat de daadwerkelijke werking en output van de software. Wees u bewust van waar de sleutels worden gegenereerd en in welke vorm.

Idealiter moeten de sleutels worden gegenereerd in geïsoleerde hardware en moet de informatie worden versleuteld met een gerenommeerd algoritme. Een voorbeeld van een zwakke die moet worden vermeden, is Data Encryption Standard, of DES, wat vandaag de dag is als gebroken beschouwd. Sleutels die in leesbare tekst worden achtergelaten - vooral in het geheugen, op schijf of in de middelste zone tussen die twee plaatsen die bekend staan ​​​​als "swap" - vormen een groot beveiligingsrisico. In het algemeen mag sleutelmateriaal de hardware waarop het is gegenereerd niet verlaten en mag het niet ontsnappen naar netwerken die voor anderen toegankelijk zijn. (Dat wil zeggen, tenzij het sleutelmateriaal is gecodeerd, in welk geval de coderingssleutel ook moet worden beveiligd.)

De sleutels van Slope, de portemonnee die deze zomer werd gehackt, werden in platte tekst ingelogd op externe servers nadat ze waren gegenereerd. Dit is het soort beveiligingslek dat had kunnen voorkomen bij een audit of open source-implementatie van de code. Portefeuilles die niet transparant zijn - met closed-source code, geen beschikbare beveiligingsaudits van derden voor het publiek - zouden rode vlaggen moeten oproepen. 

Beveiliging van portemonnee voor sleutelopslag

Nadat de sleutels zijn gegenereerd, ze moeten ergens worden opgeslagen - nooit in platte tekst, altijd gecodeerd. Maar alleen het bezit van het apparaat waarop de sleutels zijn opgeslagen, staat niet noodzakelijk gelijk aan het bezit en de controle van de sleutel. Er moet rekening worden gehouden met veel factoren, zoals de beveiliging van de toeleveringsketen van het apparaat, hoe verbonden het apparaat is en met welke andere componenten het apparaat samenwerkt. Bovendien heeft elke opslagmethode zijn eigen afwegingen tussen beveiliging, toegankelijkheid, onderhoudbaarheid en bruikbaarheid.

Hieronder splitsen we de meest voorkomende categorieën op basis van het bijbehorende niveau van waargenomen risico. 

Hoger risico: “hot” wallets

Het concept heeft eigenlijk niet veel met temperatuur te maken. Als het gaat om belangrijke opslagopties, wordt een portemonnee als "hot" beschouwd als deze is verbonden met internet. Een portemonnee wordt daarentegen als 'koud' beschouwd als deze offline en geïsoleerd is. Als al het andere gelijk is, zijn cold wallets veiliger dan hot wallets, maar ze zijn ook moeilijker toegankelijk en te gebruiken. Een portemonnee die is verbonden met een netwerk is vatbaarder voor hacks omdat het aanvallers meer kansen geeft op toegang om kwetsbaarheden te ontdekken en te exploiteren.

Hot wallets kunnen verschillende vormen aannemen.

• Verbonden software: online databases, applicatiegeheugen van telefoon of webserver, browserextensies

Dit zijn de meest risicovolle opties. Hier heeft de portefeuillesoftware, al dan niet bewaard, directe toegang tot de sleutels - en dat alles terwijl ze verbonden zijn met het externe internet. De sleutels moeten idealiter worden gecodeerd en de andere set sleutels die wordt gebruikt om ze te coderen, moet worden opgeslagen in een speciaal sleutelbeheersysteem (KMS) met zeer beperkte toegangscontroles, zoals een sleutelhanger voor het besturingssysteem of een cloudsleutelbeheersysteem.

Voor op software gebaseerde hot wallets is het van cruciaal belang om het sleutelbeheer en de autorisatie te isoleren van de rest van de softwarecomponenten. Er kunnen problemen optreden bij het loggen, foutbeheer en geheugenbeheer (vooral op heap gebaseerd, waarbij sleutels mogelijk niet correct worden "op nul gezet" of gewist), die allemaal per ongeluk wachtwoorden, coderingssleutels, ondertekeningssleutels of andere gevoelige kunnen lekken cryptografisch materiaal. Wanneer dat gebeurt, kunnen indringers ongeoorloofde toegang krijgen via verbonden applicaties of webservers, zijkanaalaanvallen of bedreigingen van binnenuit.

Ongeacht hoe een service zichzelf labelt, als de ondertekeningssleutels op enig moment in het geheugen van het online systeem ongecodeerd zijn, moet het model worden beschouwd als een hot software wallet. (Zelfs als de sleutels later in rust worden bewaard in een beveiligde enclave.)

• Verbonden hardware: speciale apparaten, mobiele beveiligde enclaves, online hardwarebeveiligingsmodules (HSM)

Verbonden hardware wordt over het algemeen als minder risicovol beschouwd dan verbonden software, maar is nog steeds niet zo veilig als koude opslag. In aangesloten hardware worden sleutels gegenereerd en leven deze alleen in speciale hardwareapparaten. Deze kunnen vervolgens worden aangesloten op interne of openbare netwerken. Dergelijke apparaten nemen over het algemeen meerdere verantwoordelijkheden op zich met betrekking tot sleutelbeheer, waaronder beveiliging voor het genereren, ondertekenen en opslaan van sleutels.

Aangesloten hardware is er in verschillende varianten. Er zijn hardware-wallets, zoals Trezor- en Ledger-apparaten, die iets geavanceerdere crypto-gebruikers vaak gebruiken. (Veel meer mensen zouden deze apparaten moeten gebruiken, omdat ze veel veiliger zijn dan het gebruik van alleen aangesloten software.) Er zijn ook hardwarebeveiligingsmodules of HSM's, die vaak worden gebruikt in meer traditionele zakelijke omgevingen, zoals degene die gevoelige gegevensverwerking verwerken , zoals creditcardbetalingen.

Apparaten zijn slechts zo veilig als de toeleveringsketen die ze heeft geproduceerd en geconfigureerd. Vraag uzelf bij het overwegen van aangesloten hardware af: hoe groot is de kans dat er met de apparaten – of de firmware – is geknoeid voordat ze in uw bezit kwamen? Om dit risico te verkleinen, kunt u apparaten het beste rechtstreeks bij vertrouwde leveranciers kopen. Laat ze rechtstreeks vanaf de bron verzenden. Zorg ervoor dat de pakketten niet beschadigd lijken te zijn - geen scheuren, scheuren, verbroken zegels, enz. - wat kan duiden op geknoei tijdens het transport. Het is ook raadzaam om voor gebruik de firmwareversie en configuratie te controleren. De stappen om dit te doen variëren afhankelijk van de hardware, maar ze moeten allemaal instructies bevatten.

Natuurlijk is er altijd de mogelijkheid dat een hardware wallet later kan worden gestolen of door een onbevoegde partij kan worden geopend. Gezien deze bedreigingen is het belangrijk om ervoor te zorgen dat hardwareportefeuilles ook veilige toegangscontrolelagen hebben - waarborgen die ervoor zorgen dat ze niet zomaar alle transacties blindelings ondertekenen. Controles kunnen wachtwoordvereisten omvatten, vragen om expliciete toestemming voor elke stap van een transactie en duidelijke Engelse samenvattingen die beschrijven wat transacties feitelijk doen. Bovendien ondersteunen de meeste hardware-wallets private key-encryptie, ook wel bekend als 'key wrapping'. Nog beter, veilige portefeuilles laten niet toe dat sleutels in onbewerkte tekst worden geëxporteerd, zelfs als men dat zou willen.

Dit is het veiligheidsniveau dat nodig is om crypto-activa echt te beschermen.

Minder riskant: “koude” portemonnees

Minder warmte, minder risico. Koude portefeuilles worden, als al het andere gelijk is, over het algemeen als veiliger beschouwd dan warme portefeuilles, hoewel ze over het algemeen ook minder bruikbaar zijn. Cold wallets worden gewoonlijk "airgapped" wallets genoemd, wat betekent dat ze geen verbinding hebben met een intern of openbaar netwerk.

Eenzaamheid is in dit geval een deugd. Airgapping omvat het implementeren van strikte fysieke isolatie- en autorisatiemaatregelen. Deze maatregelen kunnen het gebruik omvatten van kooien van Faraday (schilden die draadloze signalen blokkeren), toegang tot biometrische gegevens (zoals vingerafdruk- of irisscanners), bewegingssensoren (om alarmen te activeren in geval van ongeautoriseerd gebruik) en SCIF's, of gevoelige compartimenten voor informatievoorzieningen (speciale gebieden voor het verwerken van gerubriceerde informatie).

Laten we enkele cold wallet-opties in meer detail bekijken.

• Airgrapp-software: offline servertoepassing

Omdat een aanvaller op elk moment een machine kan stelen of online kan nemen, moeten cold wallets worden ontworpen met beveiligingssystemen die standhouden, zelfs als ze online worden gebracht. Sleutels moeten worden opgesplitst in sleutelscherven - waarbij de stukken opnieuw moeten worden samengevoegd om bruikbaar te worden gemaakt - via een standaardmethode, zoals Shamir's Secret Sharing of Multi-Party Computation. Hardware voor speciale doeleinden, zoals HSM's, wordt ten zeerste aanbevolen boven aangesloten software, omdat deze over het algemeen meer bedieningselementen bieden.

• Airgrapped hardware: offline hardware portemonnee, offline hardware beveiligingsmodule (HSM)

Deze oplossing wordt als de veiligste van allemaal beschouwd. Net als bij de vorige categorie, moet men ervan uitgaan dat de hardware kan worden gestolen en online kan worden meegenomen. Om die reden is het opnieuw belangrijk dat deze systemen goed geïmplementeerde toegangscontrolelagen bevatten, zoals eerder besproken. Veel HSM-leveranciers hebben een quorum van fysieke smartcards nodig om samen te komen voordat toegang tot sleutels kan worden ontgrendeld. Zelfs als het apparaat geen beeldscherm heeft, zou het gebruikers toch een manier moeten bieden om de details van transacties te verifiëren.

Omdat cold of airgapped wallets de veiligste categorie zijn, worden de meeste fondsen die door grote spelers worden beheerd, op deze manier opgeslagen. Grote retaildiensten, zoals Coinbase, Gemini, Kraken en anderen, evenals diensten voor institutionele gebruikers zoals Anchorage, behoren tot degenen die dit doen. Veel van deze spelers kiezen ervoor om een ​​andere verdedigingslinie te hebben in de vorm van back-ups en herstel, voor het geval ze - de hemel verhoede - de toegang verliezen of machines beschadigd, gestolen of vernietigd worden.

Back-ups en herstel

Van handtekeningsleutels moet altijd een back-up worden gemaakt nadat ze zijn versleuteld. Het is van cruciaal belang om redundantie te hebben van zowel versleutelde ondertekeningssleutels als sleutels voor het inpakken van sleutels. Methoden om een ​​back-up te maken van een ondertekeningssleutel verschillen, maar men moet altijd de voorkeur geven aan hardware-native oplossingen.

Voor hardware-wallets bevatten back-ups meestal een seed-frase van 12 woorden waarvan de privésleutels zijn afgeleid. Deze seed-zin moet niet-digitaal worden opgeslagen (denk aan papier, metaal) en op de meest veilige manier die beschikbaar is (een fysieke kluis thuis, in een bankkluis). De frase kan worden opgesplitst in delen die geografisch verspreid zijn om een ​​gemakkelijk compromitteren van het hele geheim te voorkomen. (Mensen verklaren deze benadering soms door te verwijzen naar de fictieve gruzielementen die duistere tovenaars effectief gebruiken om hun ziel te "back-uppen" in Harry Potter.)

Veel HSM's gaan standaard enkele van de uitdagingen aan die verband houden met back-up en herstel. Standaard hebben mechanismen die sleutels kunnen exporteren die standaard zijn versleuteld met toegangscontroles. Als aan de toegangscontroles is voldaan, kunnen sleutels vervolgens worden geïmporteerd in andere HSM's. Het is handig dat vloten van HSM's ook kunnen worden voorzien van een gemeenschappelijke coderingssleutel, afgeleid van een quorum van smartcards. Door de hardware op deze manier te ontkoppelen van de belangrijkste materialen, worden single points of failure voorkomen.

Ten slotte moeten menselijke factoren worden aangepakt. Herstelmechanismen moeten bestand zijn tegen de tijdelijke of permanente onbeschikbaarheid van personen die betrokken zijn bij accountbeheeractiviteiten. Individuen moeten ervoor zorgen dat naaste familieleden of andere vertrouwde partijen de sleutels kunnen terugkrijgen in geval van overlijden of andere noodsituaties. Groepsactiviteiten zouden ondertussen een quorum moeten definiëren - zoals bijvoorbeeld 2-uit-3 of 3-uit-5 - dat redelijkerwijs kan functioneren ondanks levensgebeurtenissen, reizen, ziekte of ongevallen.

Portefeuillebeveiliging voor sleutelgebruik

Nadat sleutels zijn gegenereerd en opgeslagen, kunnen ze worden gebruikt om digitale handtekeningen te maken die transacties autoriseren. Hoe meer software- en hardwarecomponenten in de mix, hoe groter het risico. Om het risico te verminderen, moeten wallets zich houden aan de volgende richtlijnen voor autorisatie en authenticatie.

• Vertrouw, maar verifieer

Portemonnees moeten authenticatie vereisen. Met andere woorden, ze moeten verifiëren dat gebruikers zijn wie ze zeggen dat ze zijn en dat alleen geautoriseerde partijen toegang hebben tot de inhoud van de portemonnee. De meest voorkomende beveiligingen hier zijn pincodes of wachtwoordzinnen. Zoals altijd moeten deze voldoende lang en complex zijn - met veel verschillende soorten tekens - om maximaal effectief te zijn. Meer geavanceerde vormen van authenticatie kunnen biometrie of op openbare sleutels gebaseerde goedkeuringen omvatten, zoals cryptografische handtekeningen van meerdere andere beveiligde apparaten.

• Rol je eigen crypto niet (opnieuw!)

Portefeuilles moeten gevestigde cryptografiebibliotheken gebruiken. Doe wat onderzoek om ervoor te zorgen dat ze worden gecontroleerd en veilig zijn om lekkage van sleutelmateriaal of volledig verlies van privésleutels te voorkomen. Om de zaak nog ingewikkelder te maken, kunnen zelfs vertrouwde bibliotheken onveilige interfaces hebben, zoals onlangs het geval was met deze Ed25519-bibliotheken. Doe voorzichtig! 

• Nonce hergebruik

Een goed bestudeerde valkuil voor sleutelgebruik is het onbedoeld hergebruik van bepaalde cryptografische handtekeningparameters. Sommige ondertekeningsschema's vereisen mogelijk een nuntius wat betekent: "nummer dat een keer wordt gebruikt", een willekeurig nummer dat alleen bedoeld is om, nou ja, één keer in een systeem te worden gebruikt. Elliptic Curve Digital Signature Algorithm (ECDSA) is zo'n handtekeningschema dat dit doet. Als een nonce opnieuw wordt gebruikt met ECDSA, kan dit leiden tot belangrijke compromissen. Verschillende andere algoritmen worden niet beïnvloed, dus zorg er zoals gewoonlijk voor dat gevestigde cryptografische bibliotheken worden gebruikt. (Bepaalde cryptografische bibliotheken zorgen voor unieke nonces door transactiegegevens te hashen, waaronder andere unieke gegevens zoals accountnonces.) Maar deze aanvalsvector is eerder misbruikt in spraakmakende hacks buiten web3, zoals deze uit 2010 Sony PlayStation 3-hack.

• Eén sleutel per doel

Een andere best practice is het vermijden van hergebruik van een sleutel voor meer dan een enkel doel. Er dienen aparte sleutels te worden bewaard voor bijvoorbeeld encryptie en ondertekening. Dit volgt het principe van “minste privilege” in geval van compromis, wat betekent dat toegang tot activa, informatie of operaties alleen mag worden beperkt tot de partijen of code die dit absoluut nodig hebben om het systeem te laten werken. Het principe van "least privilege" kan, indien correct geïmplementeerd, de explosieradius van een succesvolle aanval drastisch beperken. Verschillende sleutels hebben verschillende vereisten voor back-ups en toegangsbeheer, afhankelijk van hun doel. In de context van web3 is het een best practice om sleutels en seed-frases tussen activa en portemonnees te scheiden, zodat het compromitteren van het ene account geen invloed heeft op een ander.

Conclusie

Het bewarende of niet bewarende karakter van sleutelbezit is niet zo zwart-wit als het conventionele denken zou doen geloven. De situatie wordt gecompliceerd door de vele bewegende delen die betrokken zijn bij sleutelbeheer - van sleutelgeneratie tot opslag tot gebruik. Elk stukje hardware of software in de keten brengt risico's met zich mee die zelfs zogenaamd niet-bewarende portemonnee-opties blootstellen aan gevaren van het bewaartype. 

Voor de toekomst verwachten we dat er meer ontwikkelingswerk zal worden gedaan om portefeuilles te beveiligen tegen aanvallen en om de hierboven besproken risico's te beperken. Verbeterpunten zijn onder meer:

• Gedeeld veilig open-source sleutelbeheer en bibliotheken voor het ondertekenen van transacties op mobiele en desktopbesturingssystemen
• Gedeelde open-source transactiegoedkeuringskaders

In het bijzonder zouden we bijzonder verheugd zijn om ontwikkeling te zien voor gedeelde en open-source:

• Bibliotheken voor het genereren van sleutels voor het implementeren van de beste beveiliging in verschillende opslagbackends (versleuteld op schijf, beveiligde hardware, enz.)
• Sleutelbeheer en bibliotheken voor het ondertekenen van transacties voor mobiele en desktopbesturingssystemen
• Kaders voor transactiegoedkeuringsstromen die sterke factorverificatie implementeren, zoals biometrie, op PKI gebaseerde goedkeuringen, autorisatieherstel, enz.

Bovenstaande lijst is niet uitputtend, maar het is een goed uitgangspunt. Dit alles wil zeggen dat de situatie ingewikkelder is dan de slogan "niet je sleutels, niet je crypto" aangeeft. Sleutelbezit is een lastige zaak gezien de vele op elkaar inwerkende onderdelen en fasen van opwekking en opslag tot gebruik. 

Als je al aan een project werkt dat een van de bovenstaande punten aanpakt, of hierin geïnteresseerd zou zijn, neem dan contact met ons op! We kijken uit naar meer vooruitgang op deze fronten.

***

Redacteur: Robert Hackett, @rhhackett

***

De standpunten die hier naar voren worden gebracht, zijn die van het individuele personeel van AH Capital Management, LLC (“a16z”) dat wordt geciteerd en zijn niet de standpunten van a16z of haar gelieerde ondernemingen. Bepaalde informatie in dit document is verkregen uit externe bronnen, waaronder van portefeuillebedrijven van fondsen die worden beheerd door a16z. Hoewel ontleend aan bronnen die betrouwbaar worden geacht, heeft a16z dergelijke informatie niet onafhankelijk geverifieerd en doet het geen uitspraken over de huidige of blijvende nauwkeurigheid van de informatie of de geschiktheid ervan voor een bepaalde situatie. Bovendien kan deze inhoud advertenties van derden bevatten; a16z heeft dergelijke advertenties niet beoordeeld en keurt de daarin opgenomen advertentie-inhoud niet goed. 

Deze inhoud is uitsluitend bedoeld voor informatieve doeleinden en mag niet worden beschouwd als juridisch, zakelijk, investerings- of belastingadvies. U dient hierover uw eigen adviseurs te raadplegen. Verwijzingen naar effecten of digitale activa zijn alleen voor illustratieve doeleinden en vormen geen beleggingsaanbeveling of aanbod om beleggingsadviesdiensten te verlenen. Bovendien is deze inhoud niet gericht op of bedoeld voor gebruik door beleggers of potentiële beleggers, en mag er in geen geval op worden vertrouwd bij het nemen van een beslissing om te beleggen in een fonds dat wordt beheerd door a16z. (Een aanbod om te beleggen in een a16z-fonds wordt alleen gedaan door middel van het onderhandse plaatsingsmemorandum, de inschrijvingsovereenkomst en andere relevante documentatie van een dergelijk fonds en moet in hun geheel worden gelezen.) Alle genoemde beleggingen of portefeuillebedrijven waarnaar wordt verwezen, of beschreven zijn niet representatief voor alle investeringen in voertuigen die door a16z worden beheerd, en er kan geen garantie worden gegeven dat de investeringen winstgevend zullen zijn of dat andere investeringen die in de toekomst worden gedaan vergelijkbare kenmerken of resultaten zullen hebben. Een lijst van investeringen die zijn gedaan door fondsen die worden beheerd door Andreessen Horowitz (met uitzondering van investeringen waarvoor de uitgevende instelling geen toestemming heeft gegeven aan a16z om openbaar te maken, evenals onaangekondigde investeringen in openbaar verhandelde digitale activa) is beschikbaar op https://a16z.com/investments /.

De grafieken en grafieken die hierin worden verstrekt, zijn uitsluitend bedoeld voor informatieve doeleinden en er mag niet op worden vertrouwd bij het nemen van een investeringsbeslissing. In het verleden behaalde resultaten zijn geen indicatie voor toekomstige resultaten. De inhoud spreekt alleen vanaf de aangegeven datum. Alle projecties, schattingen, voorspellingen, doelstellingen, vooruitzichten en/of meningen die in deze materialen worden uitgedrukt, kunnen zonder voorafgaande kennisgeving worden gewijzigd en kunnen verschillen of in strijd zijn met meningen van anderen. Zie https://a16z.com/disclosures voor aanvullende belangrijke informatie.