Lommeboksikkerhet: «Non-Custodial» feilslutningen

Det ofte siterte uttrykket "ikke dine nøkler, ikke din krypto" formidler puristens filosofi om kryptografisk nøkkelhåndtering. I denne lommeboksikkerhetsmodellen er det bare et individ (eller en gruppe via "multisig") som har direkte og enerådende kontroll over sine egne private nøkler – og har derfor ekte eierskap til kryptoaktiva. Krypto-lommebøker som følger denne harde tilnærmingen kalles "ikke-forvaring", noe som betyr at ingen eksterne parter har tilgang til nøkler.

Bortsett fra, ikke så fort. Situasjonen er ikke så enkel. En rekke høyprofilerte "ikke-forvarende" lommebokhack – inkludert Slope lommebok hack som kompromitterte mer enn 8,000 kontoer i august Trinity lommebok hack som mistet mer enn 2 millioner dollar av IOTA-tokens i 2020 Hacking av paritetslommebok som tillot en angriper å stjele 150,000 2017 ETH i XNUMX, pluss oppdagelser av forskjellige sårbarheter i maskinvarelommeboken, og andre hendelser – undergraver det konvensjonelle skillet mellom varetektsbaserte og ikke-forvarende lommebøker. I mange av disse tilfellene fant ofre som trodde de brukte en lommebok uten varetekt at angripere var i stand til å kapre de ettertraktede nøklene deres. En selvmotsigelse, ikke sant?

Faktisk er historien mer kompleks enn et slagord kan fange opp. Ikke-forvarende lommebøker gir egentlig ikke brukerne full kontroll over nøklene sine. Det er fordi lommebøker er typisk opprettet av, og operert via, andres programvare eller maskinvare. Brukere setter hele tiden sin lit til andre mennesker, produkter og dataprogrammer. De aksepterer bruk av blockchain-kommandolinjegrensesnitt, lommebokprogramvare og -enheter, sentraliserte plattformer, smart kontraktskode, desentraliserte applikasjoner og alle de forskjellige lommebokene koblingsintegrasjoner i mellom. Hvert berøringspunkt legger til risiko; summen av alle disse sammenlåsende delene knuser illusjonen om den ikke-forvarende lommeboken.

Forvaring er i virkeligheten ikke-binære. Det som til å begynne med kan virke som ikke-forvaringspliktig, kan faktisk innebære mange forvaringselementer som folk ofte tar for gitt. Den tradisjonelle dikotomien – forvaring vs. ikke-forvaring – er falsk. 

I stedet er det bedre å betrakte lommebøker med mer nyanser. Nøkkelspørsmålene å stille er: Hvor stor en angrepsoverflate er jeg komfortabel med å akseptere, og hvor mange ansvar er jeg villig til å ta på meg i mitt forsøk på å eliminere tillit til tredjeparter? Generelt kan nøkkelhåndtering – grunnlaget for lommeboksikkerhet – deles inn i tre områder, som hver har unike muligheter for eksponering. Underkategoriene er som følger:

1. Nøkkelgenerasjon (opprette kryptografiske nøkler)

2. Oppbevaring av nøkkel (sikring av nøkler i ro)

3. Nøkkelbruk (sette nøkler på jobb)

Denne oversikten er ment å hjelpe web3-brukere bedre å forstå vanskelighetene som er involvert i å sikre sine eiendeler ved hjelp av rubrikken ovenfor. Videre tar vi sikte på å hjelpe ingeniører med å identifisere og støtte opp om hyppige feilpunkter i lommebokutvikling. Vi håper at bruk av denne veiledningen – hentet fra vår mange års kombinerte erfaring med å bygge krypto- og sikkerhetssystemer på tvers av Docker, Anchorage, Facebook og a16z krypto – vil hjelpe folk til å unngå sikkerhetsuhell, enten de samhandler med, deltar i eller bygge web3-teknologi.

Nedenfor dekker vi vanlige funksjoner og fallgruver ved sikkerhet og depotplattformer for kryptolommebok slik de eksisterer i dag. Vi dekker også områder vi mener krever mest oppmerksomhet og utvikling i de kommende månedene og årene for å forbedre sikkerheten til brukernes web3-opplevelser.

Lommeboksikkerhet for nøkkelgenerering

Enhver diskusjon om lommeboksikkerhet må begynne med nøkkelgenerering, prosessen med å lage kryptografiske nøkler. Enten lommeboken regnes som depotbevarende eller ikke-depot, er sikkerhetsegenskapene til nøkkelgenereringstrinnet avgjørende for nøklenes sikkerhet deretter. Under nøkkelgenerering er det tre overordnede bekymringer å huske på: bruk av pålitelig kode, implementering av koden på riktig måte og sikker håndtering av utdata.

Hvis du ikke er en kryptoekspert, kan det være vanskelig å bekrefte at alle de følgende faktorene blir gjort av boken. Sjekk for å se om du har tilgang til en pålitelig revisjonsrapport, som noen lommebokleverandører publiserer på sine offisielle nettsteder eller Github-depoter. I stedet for det, gjør din egen forskning for å prøve å finne ut om det er et anerkjent selskap bak lommeboken. Hvis informasjonen er sparsom, kan betydelig bruker- og utvikleraktivitet være den neste indikatoren på omdømme.

Følg disse retningslinjene for å redusere risikoeksponeringen. Hvis en lommebok ikke består kontrollene nedenfor, løp unna!

• Bruk lommebøker som ikke ruller sin egen krypto

Kryptografer har et ordtak: "ikke rull din egen krypto." Hovedsaken er lik ordtaket "ikke oppfinn hjulet på nytt." Hjulet er fint som det er, og ethvert forsøk på å gjenoppbygge en fra bunnen av vil sannsynligvis resultere i et dårligere produkt. Det samme gjelder krypto, en vitenskap som er vanskelig å få helt riktig. Koden som komponerer en lommebok bør ha et rykte for å fungere godt. Å velge dårlig skrevet programvare – eller forsøke å utvikle sitt eget alternativ de novo – kan føre til uhell som nøkkellekkasje eller avsløring av hemmelig informasjon til uautoriserte parter. Dette er hva som lå bak en nylig utnyttet sårbarhet i Profanitys forfengelighetsadresseverktøy. Før noe annet bør det være klart at den aktuelle lommeboken bruker et revidert og anerkjent nøkkelgenereringsbibliotek og -prosess.

• Bruk lommebøker som måler to ganger og kutt igjen og igjen

Selv om koden bruker anerkjente kryptografibiblioteker, må den fortsatt integreres riktig. Kontrollert programvare vil vanligvis sette opp riktige parametere som standard, men det kan være hull i utførelsen. For eksempel kreves en sterk kilde til entropi, eller dose matematisk tilfeldighet, for å gjøre nøkler som skal genereres uforutsigbare og derfor sikrere. For visse nøkkelgenereringsprosesser, som for mange Multi-Party Computation (MPC) algoritmer, der mange separate nøkler – eller shards, fragmenter av nøkler – må genereres og koordineres, bør lommeboken følge den nøyaktige protokollen som spesifisert av algoritme. Algoritmen kan også kreve flere runder med beregninger samt oppfriskende nøkler, som lommeboken må integreres riktig for å opprettholde sikkerheten til midlene.

• Bruk en lommebok som kan holde på hemmeligheter

Den siste fasen av nøkkelgenereringsprosessen involverer selve driften og produksjonen av programvaren. Vær oppmerksom på hvor nøklene blir generert og i hvilken form.

Ideelt sett bør nøklene genereres i isolert maskinvare, og informasjonen bør krypteres med en anerkjent algoritme. Et eksempel på en svak en som bør unngås er Data Encryption Standard, eller DES, som er i dag anses som ødelagt. Nøkler som er igjen i klartekst - spesielt i minnet, på disken eller i midtsonen mellom de to stedene kjent som "bytte" - er en stor sikkerhetsrisiko. Generelt bør nøkkelmateriale ikke etterlate maskinvaren den er generert på, og bør ikke unnslippe til nettverk som er tilgjengelig for andre. (Det vil si med mindre nøkkelmaterialet er kryptert, i så fall må krypteringsnøkkelen også være sikret.)

Nøklene til Slope, lommeboken som ble hacket i sommer, ble logget i klartekst til eksterne servere etter å ha blitt generert. Dette er den typen sikkerhetsbrudd som kunne ha dukket opp i en revisjon eller åpen kildekodeimplementering av koden. Lommebøker som mangler gjennomsiktighet – med lukket kildekode, ingen tilgjengelige tredjeparts sikkerhetsrevisjoner for offentligheten – bør heve røde flagg. 

Lommeboksikkerhet for nøkkellagring

Etter at nøkler er generert, de må oppbevares et sted – aldri i ren tekst, alltid kryptert. Men bare å eie enheten som nøklene er lagret på, er ikke nødvendigvis det samme som nøkkeleierskap og -kontroll. Mange faktorer som enhetens forsyningskjedesikkerhet, hvor tilkoblet enheten er og hvilke andre komponenter enheten samhandler med må vurderes. Videre har hver lagringsmetode sitt eget sett med avveininger mellom sikkerhet, tilgjengelighet, vedlikeholdbarhet og brukervennlighet.

Nedenfor bryter vi ned de vanligste kategoriene basert på deres tilhørende nivå av opplevd risiko. 

Høyere risiko: "varme" lommebøker

Konseptet har faktisk ikke så mye med temperatur å gjøre. Når det gjelder nøkkellagringsalternativer, anses en lommebok som "hot" hvis den er koblet til internett. En lommebok anses på den annen side som "kald" hvis den er offline og isolert. Alt annet likt er kalde lommebøker sikrere enn varme lommebøker – men de er også vanskeligere å få tilgang til og bruke. En lommebok som er koblet til et hvilket som helst nettverk er mer utsatt for hacks, da det gir angripere flere sjanser for tilgang til å oppdage og utnytte sårbarheter.

Hot wallets kan ha flere former.

• Tilkoblet programvare: online databaser, telefon- eller webserverapplikasjonsminne, nettleserutvidelser

Dette er de mest risikable alternativene. Her har lommebokprogramvaren, varebevaring eller ikke, direkte tilgang til nøklene – alt mens den er koblet til eksternt internett. Nøklene bør ideelt sett være krypterte, og det andre settet med nøkler som brukes til å kryptere dem, bør lagres i et dedikert nøkkeladministrasjonssystem (KMS) med svært begrensede tilgangskontroller, for eksempel en nøkkelring i et operativsystem eller et skynøkkelstyringssystem.

For programvarebaserte hot wallets er det avgjørende å isolere nøkkeladministrasjonen og autorisasjonen fra resten av programvarekomponentene. Problemer kan dukke opp i logging, feilhåndtering og minneadministrasjon (spesielt heap-basert, der nøkler kanskje ikke blir riktig "nullstilt" eller slettet), som alle feilaktig kan lekke passord, krypteringsnøkler, signeringsnøkler eller annet sensitivt kryptografisk materiale. Når det skjer, kan inngripere få uautorisert tilgang gjennom tilkoblede applikasjoner eller webservere, sidekanalangrep eller innsidetrusler.

Uansett hvordan en tjeneste merker seg selv, hvis signeringsnøklene til enhver tid er ukrypterte i onlinesystemets minne, bør modellen betraktes som en hot programvarelommebok. (Selv om nøklene senere lagres i ro i en sikker enklave.)

• Tilkoblet maskinvare: spesialenheter, mobile sikre enklaver, online maskinvaresikkerhetsmoduler (HSM)

Tilkoblet maskinvare anses generelt som mindre risikabelt enn tilkoblet programvare, men det er fortsatt ikke like sikkert som kjølelagring. I tilkoblet maskinvare genereres nøkler og lever kun inne i spesialutstyrte maskinvareenheter. Disse kan da kobles enten til interne eller offentlige nettverk. Slike enheter tar vanligvis flere ansvar knyttet til nøkkeladministrasjon, inkludert sikkerhet for nøkkelgenerering, signering og lagring.

Tilkoblet maskinvare kommer i flere varianter. Det er maskinvare-lommebøker, som Trezor- og Ledger-enheter, som litt mer sofistikerte kryptobrukere vanligvis bruker. (Mange flere mennesker burde bruke disse enhetene, siden de er mye tryggere enn å bruke tilkoblet programvare alene.) Det finnes også maskinvaresikkerhetsmoduler, eller HSM-er, som ofte brukes i mer tradisjonelle forretningsinnstillinger, for eksempel de som håndterer sensitiv databehandling , som kredittkortbetalinger.

Enheter er bare like sikre som forsyningskjeden som produserte og konfigurerte dem. Når du vurderer tilkoblet maskinvare, spør deg selv: Hva er sannsynligheten for at enten enhetene – eller fastvaren – ble tuklet med før de kom i din besittelse? For å redusere denne risikoen er det best å kjøpe enheter direkte fra pålitelige leverandører. Få dem sendt direkte fra kilden. Pass på at pakkene ikke ser ut til å være kompromittert – ingen rifter, rifter, ødelagte forseglinger osv. – noe som kan tyde på tukling under transport. Det er også tilrådelig å verifisere fastvareversjonen og konfigurasjonen før bruk. Trinnene for å gjøre det varierer avhengig av maskinvaren, men alle bør gi instruksjoner.

Selvfølgelig er det alltid en mulighet for at en maskinvarelommebok senere kan bli stjålet eller åpnet av en uautorisert part. Gitt disse truslene, er det viktig å sørge for at maskinvarelommebøker også har sikre tilgangskontrolllag – sikkerhetstiltak som sikrer at de ikke bare blindt signerer alle transaksjoner. Kontroller kan inkludere passordkrav, spørsmål som ber om eksplisitt tillatelse for hvert trinn i en transaksjon, og enkle engelske sammendrag som beskriver hva transaksjoner faktisk gjør. I tillegg støtter de fleste maskinvarelommebøker privat nøkkelkryptering, også kjent som "nøkkelinnpakning". Enda bedre, sikre lommebøker vil ikke tillate eksport av nøkler i ren tekstform, selv om man ønsket at de skulle være det.

Dette er sikkerhetsnivået som kreves for å virkelig sikre kryptoaktiva.

Mindre risikabelt: "kalde" lommebøker

Mindre varme, lavere risiko. Kalde lommebøker anses, alt annet likt, generelt som sikrere enn varme lommebøker, selv om de også generelt sett er mindre brukbare. Kalde lommebøker kalles ofte "luftgappede" lommebøker, noe som betyr at de ikke har noen forbindelse til noe internt eller offentlig nettverk.

Ensomhet er en dyd i dette tilfellet. Airgapping innebærer å implementere strenge fysiske isolasjons- og autorisasjonstiltak. Disse tiltakene kan inkludere bruk av Faraday-bur (skjold som blokkerer trådløse signaler), biometrisk tilgang (som fingeravtrykk eller irisskannere), bevegelsessensorer (for å utløse alarmer ved uautorisert bruk), og SCIF-er, eller sensitive rominformasjonsfasiliteter (spesielle områder for behandling av gradert informasjon).

La oss se nærmere på noen kalde lommebokalternativer.

• Airgrapped programvare: offline serverapplikasjon

Fordi en angriper kan stjele eller ta en maskin på nettet når som helst, bør kalde lommebøker utformes med sikkerhetssystemer som holder stand selv om de bringes online. Nøkler bør deles i nøkkelskår – noe som krever at brikkene skal settes sammen igjen for å gjøres brukbare – gjennom en standardmetode, for eksempel Shamir's Secret Sharing eller Multi-Party Computation. Maskinvare for spesialformål, for eksempel HSM-er, anbefales på det sterkeste fremfor tilkoblet programvare, da de vanligvis tilbyr flere kontroller.

• Airgrapped maskinvare: frakoblet maskinvarelommebok, frakoblet maskinvaresikkerhetsmodul (HSM)

Denne løsningen regnes som den sikreste av alle. I likhet med den forrige kategorien, bør man anta at maskinvaren kan bli stjålet og tatt på nettet. Av den grunn er det viktig igjen for disse systemene å inkludere riktig implementerte tilgangskontrolllag, som diskutert tidligere. Mange HSM-leverandører krever et quorum av fysiske smartkort for å komme sammen før tilgang til nøkler kan låses opp. Selv om enheten ikke har en skjerm, bør den tilby en måte for brukere å verifisere detaljene i transaksjoner.

Fordi kalde eller luftspaltede lommebøker er den sikreste kategorien, lagres de fleste midler som forvaltes av store aktører på denne måten. Store detaljhandelstjenester, som Coinbase, Gemini, Kraken og andre, samt tjenester for institusjonelle brukere som Anchorage, er blant dem som gjør det. Mange av disse spillerne velger å ha en annen forsvarslinje i form av sikkerhetskopiering og gjenoppretting, bare i tilfelle – himmelen forby – de mister tilgang, eller maskiner blir ødelagt, stjålet eller ødelagt.

Sikkerhetskopiering og gjenoppretting

Signeringsnøkler skal alltid sikkerhetskopieres etter å ha blitt kryptert. Det er avgjørende å ha redundans for både krypterte signeringsnøkler og nøkkelinnpakningsnøkler. Metoder for å sikkerhetskopiere en signeringsnøkkel er forskjellige, men man bør alltid foretrekke hardware-native løsninger.

For maskinvare-lommebøker involverer sikkerhetskopier vanligvis en 12-ords ren tekstfrøfrase som private nøkler er avledet fra. Denne frøfrasen bør lagres ikke-digitalt (tenk papir, metall) og på den sikreste måten som er tilgjengelig (et fysisk hvelv hjemme, inne i et bankhvelv). Uttrykket kan deles inn i deler som er geografisk fordelt for å forhindre lett kompromittering av hele hemmeligheten. (Folk forklarer noen ganger denne tilnærmingen ved å referere til de fiktive horcruxene som mørke trollmenn bruker effektivt for å "sikkerhetskopiere" sjelene sine i Harry Potter.)

Mange HSM-er håndterer naturlig nok noen av utfordringene knyttet til sikkerhetskopiering og gjenoppretting. Standard har mekanismer som kan eksportere nøkler som som standard er kryptert med tilgangskontroller. Hvis tilgangskontrollene er oppfylt, kan nøkler importeres til andre HSM-er. Hensiktsmessig kan flåter av HSM-er også utstyres med en felles krypteringsnøkkel, avledet fra et quorum av smartkort. Å koble maskinvaren fra nøkkelmaterialene på denne måten bidrar til å unngå enkeltpunkter for feil.

Til slutt må menneskelige faktorer adresseres. Gjenopprettingsmekanismer bør være i stand til å motstå midlertidig eller permanent utilgjengelighet for en person som er involvert i kontoadministrasjonsoperasjoner. Enkeltpersoner bør sørge for å sørge for måter for nære familiemedlemmer eller andre betrodde parter å gjenopprette nøkler i tilfelle dødsfall eller andre nødssituasjoner. Gruppeoperasjoner bør i mellomtiden definere et quorum – for eksempel 2-av-3 eller 3-av-5, for eksempel – som med rimelighet kan fungere til tross for livshendelser, reiser, sykdom eller ulykker.

Lommeboksikkerhet for nøkkelbruk

Etter at nøkler er generert og lagret, kan de brukes til å lage digitale signaturer som autoriserer transaksjoner. Jo flere programvare- og maskinvarekomponenter i blandingen, jo større er risikoen. For å redusere risiko, bør lommebøker overholde følgende retningslinjer for autorisasjon og autentisering.

• Stol på, men bekreft

Lommebøker bør kreve autentisering. Med andre ord bør de verifisere at brukerne er den de sier de er, og at kun autoriserte parter har tilgang til innholdet i lommeboken. De vanligste sikkerhetstiltakene her er PIN-koder eller passordfraser. Som alltid bør disse være tilstrekkelig lange og komplekse – med mange forskjellige typer tegn – til å være maksimalt effektive. Mer avanserte former for autentisering kan inkludere biometri eller offentlig nøkkelkrypteringsbaserte godkjenninger, for eksempel kryptografiske signaturer fra flere andre sikrede enheter.

• Ikke rull din egen krypto (igjen!)

Lommebøker bør bruke veletablerte kryptografibiblioteker. Gjør noen undersøkelser for å sikre at de er revidert og trygge for å unngå lekkasje av nøkkelmateriale eller fullstendig tap av private nøkler. Det kompliserer saken, selv pålitelige biblioteker kan ha usikre grensesnitt, slik det nylig var tilfelle med disse Ed25519-bibliotekene. Vær forsiktig! 

• Ikke gjenbruk

En godt studert fallgruve for nøkkelbruk er utilsiktet gjenbruk av visse kryptografiske signaturparametere. Noen signaturordninger kan kreve en nuncio som betyr "nummer brukt én gang," et vilkårlig tall bare ment å brukes, vel, én gang i et system. Elliptic Curve Digital Signature Algorithm (ECDSA) er en slik signaturordning som gjør det. Hvis en nonce gjenbrukes med ECDSA, kan det føre til viktige kompromisser. Ulike andre algoritmer påvirkes ikke, så som vanlig, sørg for at veletablerte kryptografiske biblioteker blir brukt. (Enkelte kryptografiske biblioteker sikrer unike nonces ved å hashe transaksjonsdata, som inkluderer andre unike data som konto nonces.) Men denne angrepsvektoren har blitt utnyttet før i høyprofilerte hacks utenfor web3, slik som denne 2010 Sony PlayStation 3 hack.

• En nøkkel per formål

En annen beste praksis er å unngå gjenbruk av en nøkkel til mer enn ett enkelt formål. Det bør oppbevares separate nøkler for for eksempel kryptering og signering. Dette følger prinsippet om "minst privilegium” i tilfelle kompromittering, noe som betyr at tilgang til alle eiendeler, informasjon eller operasjoner kun skal begrenses til partene eller koden som absolutt krever det for at systemet skal fungere. Prinsippet om "minste privilegium" kan, når det implementeres riktig, drastisk begrense eksplosjonsradiusen til et vellykket angrep. Ulike nøkler vil ha ulike krav til sikkerhetskopiering og tilgangsadministrasjon avhengig av formålet. I sammenheng med web3 er det en beste praksis å skille nøkler og frøfraser mellom eiendeler og lommebøker, så kompromiss med én konto påvirker ikke noen annen.

konklusjonen

Den forvarende eller ikke-forvarende karakteren til nøkkeleierskap er ikke så svart-hvitt som konvensjonell tenkning ville ha en tro. Situasjonen er komplisert av de mange bevegelige delene som er involvert i nøkkelhåndtering – fra nøkkelgenerering til lagring til bruk. Hvert stykke maskinvare eller programvare langs kjeden introduserer risikoer som utsetter selv antatt ikke-depotbaserte lommebokalternativer for farer av typen frihetsberøvelse. 

For fremtiden forventer vi at det gjøres mer utviklingsarbeid for å sikre lommebøker mot angrep og for å redusere risikoen diskutert ovenfor. Forbedringsområder inkluderer:

• Delte sikker åpen kildekode-nøkkeladministrasjon og transaksjonssigneringsbiblioteker på tvers av mobile og stasjonære operativsystemer
• Delte rammeverk for godkjenning av transaksjoner med åpen kildekode

Spesielt vil vi være spesielt glade for å se utvikling for delt og åpen kildekode:

• Nøkkelgenereringsbiblioteker for å implementere klassens beste sikkerhet på tvers av forskjellige lagringsbackends (kryptert på disk, sikker maskinvare, etc.)
• Biblioteker for nøkkeladministrasjon og transaksjonssignering for mobile og stasjonære operativsystemer
• Rammer for transaksjonsgodkjenningsflyter som implementerer sterk faktorverifisering som biometri, PKI-baserte godkjenninger, autorisasjonsgjenoppretting, etc.

Listen ovenfor er ikke uttømmende, men det er et godt utgangspunkt. Alt dette er å si, situasjonen er mer komplisert enn slagordet "ikke nøklene dine, ikke din krypto" indikerer. Nøkkelbesittelse er en vanskelig sak gitt de mange samvirkende delene og fasene fra generering og lagring gjennom bruk. 

Hvis du allerede jobber med et prosjekt som tar for seg noen av de ovennevnte, eller er interessert i å gjøre det, vennligst ta kontakt! Vi ser frem til mer fremgang på disse frontene.

***

Redaktør: Robert Hackett, @rhhackett

***

Synspunktene som er uttrykt her, er de fra individuelle AH Capital Management, LLC (“a16z”) personell som er sitert og er ikke synspunktene til a16z eller dets tilknyttede selskaper. Visse opplysninger her er innhentet fra tredjepartskilder, inkludert fra porteføljeselskaper av fond forvaltet av a16z. Selv om a16z er hentet fra kilder som antas å være pålitelige, har ikke a16z uavhengig verifisert slik informasjon og gir ingen representasjoner om den nåværende eller varige nøyaktigheten til informasjonen eller dens hensiktsmessighet for en gitt situasjon. I tillegg kan dette innholdet inkludere tredjepartsannonser; aXNUMXz har ikke vurdert slike annonser og støtter ikke noe reklameinnhold som finnes deri. 

Dette innholdet er kun gitt for informasjonsformål, og bør ikke stoles på som juridisk, forretningsmessig, investerings- eller skatterådgivning. Du bør rådføre deg med dine egne rådgivere om disse sakene. Referanser til verdipapirer eller digitale eiendeler er kun for illustrasjonsformål, og utgjør ikke en investeringsanbefaling eller tilbud om å tilby investeringsrådgivningstjenester. Videre er dette innholdet ikke rettet mot eller ment for bruk av noen investorer eller potensielle investorer, og kan ikke under noen omstendigheter stoles på når du tar en beslutning om å investere i et fond som forvaltes av a16z. (Et tilbud om å investere i et a16z-fond vil kun gis av det private emisjonsmemorandumet, tegningsavtalen og annen relevant dokumentasjon for et slikt fond og bør leses i sin helhet.) Eventuelle investeringer eller porteføljeselskaper nevnt, referert til, eller beskrevet er ikke representative for alle investeringer i kjøretøy forvaltet av a16z, og det kan ikke gis noen garanti for at investeringene vil være lønnsomme eller at andre investeringer som gjøres i fremtiden vil ha lignende egenskaper eller resultater. En liste over investeringer foretatt av fond forvaltet av Andreessen Horowitz (unntatt investeringer som utstederen ikke har gitt tillatelse til at a16z kan offentliggjøre så vel som uanmeldte investeringer i børsnoterte digitale eiendeler) er tilgjengelig på https://a16z.com/investments /.

Diagrammer og grafer gitt i er kun for informasjonsformål og bør ikke stoles på når du tar investeringsbeslutninger. Tidligere resultater er ikke en indikasjon på fremtidige resultater. Innholdet taler kun fra den angitte datoen. Eventuelle anslag, estimater, prognoser, mål, prospekter og/eller meninger uttrykt i dette materialet kan endres uten varsel og kan avvike eller være i strid med meninger uttrykt av andre. Vennligst se https://a16z.com/disclosures for ytterligere viktig informasjon.