Sicurezza del portafoglio: l'errore "non custodito" di PlatoBlockchain Data Intelligence. Ricerca verticale. Ai.

Sicurezza del portafoglio: l'errore "non detentivo".

L'espressione comunemente citata "non le tue chiavi, non la tua crittografia" trasmette la filosofia purista della gestione delle chiavi crittografiche. In questo modello di sicurezza del portafoglio, solo un individuo (o un gruppo tramite "multisig") ha il controllo diretto ed esclusivo sulle proprie chiavi private e, quindi, ha la vera proprietà delle proprie risorse crittografiche. I portafogli crittografici che aderiscono a questo approccio rigido sono chiamati "non custoditi", il che significa che nessuna parte esterna ha accesso alle chiavi.

Tranne, non così in fretta. La situazione non è così semplice. Una serie di hack di portafoglio "non detentivi" di alto profilo, incluso il Hack del portafoglio in pendenza che nel mese di agosto ha compromesso più di 8,000 account, il Trucchi per il portafoglio Trinity che ha perso più di $ 2 milioni di token IOTA nel 2020, il Trucco del portafoglio di parità che ha permesso a un attaccante di rubare 150,000 ETH nel 2017, oltre a scoperte di vari vulnerabilità del portafoglio hardwaree altri incidenti – mina la distinzione convenzionale tra portafogli di custodia e non di custodia. In molti di questi casi, le vittime che credevano di utilizzare un portafoglio non detentivo hanno scoperto che gli aggressori erano in grado di dirottare le loro ambite chiavi. Una contraddizione, no?

In effetti, la storia è più complessa di quanto uno slogan possa catturare. I portafogli non di custodia in realtà non danno agli utenti il ​​pieno controllo delle proprie chiavi. Questo perché i portafogli sono in genere creato da, e gestito tramite, software o hardware di qualcun altro. Gli utenti ripongono costantemente la loro fiducia in altre persone, prodotti e programmi per computer. Accettano l'utilizzo di interfacce a riga di comando blockchain, software e dispositivi di portafoglio, piattaforme centralizzate, codice smart contract, applicazioni decentralizzate e tutti i vari wallet integrazioni di connessione in mezzo. Ogni punto di contatto aggiunge rischio; la somma di tutte queste parti ad incastro manda in frantumi l'illusione del portafoglio non custodito.

La custodia è, in realtà, no-binario. Ciò che a prima vista potrebbe sembrare non detentivo può in realtà coinvolgere molti elementi di custodia la cui affidabilità le persone spesso danno per scontata. La dicotomia tradizionale – custodia vs. non custodia – è falsa. 

Invece, è meglio considerare i portafogli con più sfumature. Le domande chiave da porsi sono: quanto è grande una superficie di attacco mi sento a mio agio ad accettare e quante responsabilità sono disposto ad assumermi nella mia ricerca per eliminare la fiducia in terze parti? In generale, la gestione delle chiavi, il fondamento della sicurezza del portafoglio, può essere suddivisa in tre aree, ognuna delle quali ha opportunità uniche di esposizione. Le sottocategorie sono le seguenti:

  1. Generazione di chiavi (creazione chiavi crittografiche)
  2. Archiviazione chiavi (chiavi di sicurezza a riposo)
  3. Utilizzo chiave (mettendo le chiavi al lavoro)

Questa panoramica ha lo scopo di aiutare gli utenti di web3 a comprendere meglio le complessità coinvolte nella protezione delle proprie risorse tramite la rubrica sopra. Inoltre, miriamo ad aiutare gli ingegneri a identificare e sostenere i frequenti punti di errore nello sviluppo del portafoglio. Ci auguriamo che l'applicazione di questa guida, frutto della nostra pluriennale esperienza combinata nella creazione di sistemi crittografici e di sicurezza su Docker, Anchorage, Facebook e a16z crypto, aiuterà le persone a evitare incidenti di sicurezza, indipendentemente dal fatto che stiano interagendo, partecipando o costruzione web3 tech.

Di seguito, trattiamo le caratteristiche comuni e le insidie ​​delle piattaforme di sicurezza e custodia dei portafogli crittografici così come esistono oggi. Copriamo anche le aree che riteniamo richiedano maggiore attenzione e sviluppo nei prossimi mesi e anni per migliorare la sicurezza delle esperienze web3 degli utenti.

Sicurezza del portafoglio di generazione di chiavi

Qualsiasi discussione sulla sicurezza del portafoglio deve iniziare con la generazione delle chiavi, il processo di creazione delle chiavi crittografiche. Indipendentemente dal fatto che il portafoglio sia considerato di custodia o non, le proprietà di sicurezza della fase di generazione delle chiavi sono fondamentali per la sicurezza delle chiavi successive. Durante la generazione delle chiavi, è necessario tenere a mente tre problemi generali: l'utilizzo di codice affidabile, l'implementazione corretta del codice e la gestione sicura dell'output.

Se non sei un esperto di criptovalute, può essere difficile verificare che tutti i seguenti fattori vengano eseguiti dal libro. Verifica se puoi accedere a un rapporto di controllo attendibile, che alcuni fornitori di portafogli pubblicano sui loro siti Web ufficiali o repository Github. Al posto di ciò, fai le tue ricerche per cercare di determinare se c'è un'azienda rispettabile dietro il portafoglio. Se le informazioni sono scarse, un'attività significativa di utenti e sviluppatori potrebbe essere il prossimo indicatore di affidabilità.

Segui queste linee guida per ridurre la tua esposizione al rischio. Se un portafoglio non supera i controlli seguenti, scappa!

  • Usa portafogli che non lanciano le proprie criptovalute

I crittografi hanno un detto: "non lanciare le tue criptovalute". L'essenza è simile all'adagio "non reinventare la ruota". La ruota va bene così com'è ed è probabile che qualsiasi tentativo di ricostruirne una da zero si traduca in un prodotto peggiore. Lo stesso vale per le criptovalute, una scienza difficile da ottenere esattamente. Il codice che compone un portafoglio dovrebbe avere la reputazione di funzionare bene. Scegliere un software scritto male o tentare di sviluppare la propria alternativa de novo – può portare a incidenti come la perdita di chiavi o la rivelazione di informazioni segrete a soggetti non autorizzati. Questo è ciò che c'era dietro una vulnerabilità sfruttata di recente in Strumento per il vanity address di Profanity. Prima di ogni altra cosa, dovrebbe essere chiaro che il portafoglio in questione utilizza una libreria e un processo di generazione di chiavi verificati e affidabili.

  • Usa portafogli che misurano due volte e tagliano ancora e ancora

Anche se il codice utilizza librerie di crittografia affidabili, deve comunque essere integrato correttamente. Il software controllato in genere imposta i parametri corretti per impostazione predefinita, ma possono esserci delle lacune nell'esecuzione. Ad esempio, è necessaria una forte fonte di entropia, o dose di casualità matematica, per rendere le chiavi da generare imprevedibili e, quindi, più sicure. Per alcuni processi di generazione delle chiavi, come per molti algoritmi di Multi-Party Computation (MPC), in cui devono essere generate e coordinate molte chiavi separate – o shard, frammenti di chiavi – il portafoglio dovrebbe seguire il protocollo preciso come specificato dal algoritmo. L'algoritmo può anche richiedere più cicli di calcolo e chiavi di aggiornamento, che il portafoglio deve integrare correttamente per mantenere la sicurezza dei fondi.

  • Usa un portafoglio in grado di mantenere segreti

La fase finale del processo di generazione delle chiavi prevede il funzionamento effettivo e l'output del software. Essere consapevoli di dove vengono generate le chiavi e in quale forma.

Idealmente, le chiavi dovrebbero essere generate in hardware isolato e le informazioni dovrebbero essere crittografate con un algoritmo affidabile. Un esempio di debole da evitare è Data Encryption Standard, o DES, che è oggi considerato rotto. Le chiavi lasciate in chiaro, specialmente in memoria, su disco o nella zona intermedia tra questi due luoghi noti come "scambio", rappresentano un grave rischio per la sicurezza. In generale, il materiale chiave non dovrebbe lasciare l'hardware su cui è stato generato e non dovrebbe fuggire su reti accessibili da altri. (Cioè, a meno che il materiale della chiave non sia crittografato, nel qual caso anche la chiave di crittografia deve essere protetta.)

Le chiavi di Slope, il portafoglio hackerato quest'estate, sono stati registrati in chiaro su server esterni dopo essere stati generati. Questo è il tipo di errore di sicurezza che potrebbe essere emerso in un controllo o in un'implementazione open source del codice. I portafogli privi di trasparenza - con codice a codice chiuso, nessun audit di sicurezza di terze parti disponibile al pubblico - dovrebbero sollevare segnali d'allarme. 

Sicurezza del portafoglio di archiviazione delle chiavi

Dopo aver generato le chiavi, dovranno essere nascosti da qualche parte, mai in chiaro, sempre crittografati. Ma semplicemente possedere il dispositivo su cui sono memorizzate le chiavi non equivale necessariamente alla proprietà e al controllo delle chiavi. Devono essere presi in considerazione molti fattori come la sicurezza della catena di approvvigionamento del dispositivo, la modalità di connessione del dispositivo e gli altri componenti con cui il dispositivo interagisce. Inoltre, ogni metodo di archiviazione ha la propria serie di compromessi tra sicurezza, accessibilità, manutenibilità e usabilità.

Di seguito, analizziamo le categorie più comuni in base al livello di rischio percepito associato. 

Rischio maggiore: portafogli "caldi".

Il concetto in realtà non ha molto a che fare con la temperatura. Quando si tratta di opzioni di archiviazione chiave, un portafoglio è considerato "caldo" se è connesso a Internet. Un portafoglio è considerato "freddo", d'altra parte, se è offline e isolato. A parità di condizioni, i cold wallet sono più sicuri degli hot wallet, ma sono anche più difficili da accedere e utilizzare. Un portafoglio connesso a qualsiasi rete è più suscettibile agli hack in quanto offre agli aggressori maggiori possibilità di accesso per scoprire e sfruttare le vulnerabilità.

Gli hot wallet possono assumere alcune forme.

  • Software connesso: database online, memoria dell'applicazione del telefono o del server Web, estensioni del browser

Queste sono le opzioni più rischiose. Qui, il software del portafoglio, custodia o meno, ha accesso diretto alle chiavi, il tutto mentre è connesso a Internet esterno. Le chiavi dovrebbero idealmente essere crittografate e l'altro set di chiavi utilizzato per crittografarle dovrebbe essere archiviato in un sistema di gestione delle chiavi (KMS) dedicato con controlli di accesso altamente limitati come un portachiavi del sistema operativo o un sistema di gestione delle chiavi cloud.

Per gli hot wallet basati su software, è fondamentale isolare la gestione e l'autorizzazione delle chiavi dal resto dei componenti software. Possono sorgere problemi nella registrazione, nella gestione degli errori e nella gestione della memoria (soprattutto basata sull'heap, in cui le chiavi potrebbero non essere correttamente "azzerate" o cancellate), tutte cose che possono far trapelare erroneamente password, chiavi di crittografia, chiavi di firma o altre informazioni sensibili materiale crittografico. Quando ciò accade, gli intrusi possono ottenere l'accesso non autorizzato tramite applicazioni o server Web connessi, attacchi del canale laterale o minacce interne.

Indipendentemente dal modo in cui un servizio si etichetta, se le chiavi di firma non sono crittografate in qualsiasi momento nella memoria del sistema online, il modello dovrebbe essere considerato un hot software wallet. (Anche se le chiavi vengono successivamente conservate a riposo in un'enclave sicura.)

  • Hardware connesso: dispositivi per scopi speciali, enclavi mobili sicure, moduli di sicurezza hardware online (HSM)

L'hardware connesso è generalmente considerato meno rischioso del software connesso, ma non è ancora sicuro come il cold storage. Nell'hardware connesso, le chiavi vengono generate e risiedono solo all'interno di dispositivi hardware per scopi speciali. Questi possono quindi essere collegati a reti interne o pubbliche. Tali dispositivi generalmente assumono molteplici responsabilità relative alla gestione delle chiavi, inclusa la sicurezza per la generazione, la firma e l'archiviazione delle chiavi.

L'hardware connesso è disponibile in diverse varietà. Esistono portafogli hardware, come i dispositivi Trezor e Ledger, che usano comunemente utenti di crittografia leggermente più sofisticati. (Molte più persone dovrebbero utilizzare questi dispositivi, poiché sono molto più sicuri rispetto all'utilizzo del solo software connesso.) Esistono anche moduli di sicurezza hardware, o HSM, che sono comunemente usati in contesti aziendali più tradizionali come quelli che gestiscono l'elaborazione di dati sensibili , come i pagamenti con carta di credito.

I dispositivi sono sicuri solo quanto la catena di approvvigionamento che li ha prodotti e configurati. Quando consideri l'hardware connesso, chiediti: qual è la probabilità che i dispositivi, o il firmware, siano stati manomessi prima di entrare in tuo possesso? Per ridurre questo rischio, è meglio acquistare i dispositivi direttamente da fornitori di fiducia. Farli spedire direttamente dalla fonte. Assicurati che i pacchi non appaiano compromessi – senza strappi, strappi, sigilli rotti, ecc. – che potrebbero indicare manomissioni durante il trasporto. Si consiglia inoltre di verificare la versione del firmware e la configurazione prima dell'uso. I passaggi per farlo variano a seconda dell'hardware, ma tutti dovrebbero fornire istruzioni.

Naturalmente, c'è sempre la possibilità che un portafoglio hardware possa essere successivamente rubato o accessibile da una parte non autorizzata. Date queste minacce, è importante assicurarsi che i portafogli hardware dispongano anche di livelli di controllo degli accessi sicuri, misure di sicurezza che assicurano che non firmino alla cieca tutte le transazioni. I controlli possono includere requisiti per la password, richieste di autorizzazione esplicita per ogni passaggio di una transazione e semplici riepiloghi in inglese che descrivono cosa stanno effettivamente facendo le transazioni. Inoltre, la maggior parte dei portafogli hardware supporta la crittografia della chiave privata, nota anche come "avvolgimento delle chiavi". Ancora meglio, i portafogli sicuri non consentiranno l'esportazione delle chiavi in ​​formato non crittografato, anche se si desidera che lo siano.

Questo è il livello di sicurezza necessario per salvaguardare veramente le risorse crittografiche.

Meno rischioso: i portafogli “freddi”.

Meno calore, minor rischio. I portafogli freddi sono, a parità di condizioni, generalmente considerati più sicuri di quelli caldi, sebbene siano generalmente anche meno utilizzabili. I portafogli freddi sono comunemente chiamati portafogli "airgapped", il che significa che non hanno alcuna connessione a nessuna rete interna o pubblica.

La solitudine è una virtù in questo caso. L'airgapping implica l'attuazione di rigorose misure di isolamento fisico e autorizzazione. Queste misure possono includere l'uso di gabbie di Faraday (scudi che bloccano i segnali wireless), l'accesso biometrico (come scanner di impronte digitali o dell'iride), sensori di movimento (per far scattare allarmi in caso di uso non autorizzato) e SCIF o strutture informative a compartimenti sensibili (speciali aree per il trattamento di informazioni classificate).

Esaminiamo alcune opzioni di portafoglio freddo in modo più dettagliato.

  • Software Airgrapped: applicazione server offline

Poiché un utente malintenzionato può rubare o portare una macchina online in qualsiasi momento, i cold wallet dovrebbero essere progettati con sistemi di sicurezza che resistono anche se vengono portati online. Le chiavi dovrebbero essere suddivise in frammenti di chiavi, che richiedono che i pezzi siano riuniti per essere resi utilizzabili, attraverso un metodo standard, come la condivisione segreta di Shamir o il calcolo multi-partito. L'hardware per scopi speciali, come gli HSM, è altamente raccomandato rispetto al software connesso poiché generalmente offre più controlli.

  • Hardware Airgrapped: portafoglio hardware offline, modulo di sicurezza hardware offline (HSM)

Questa soluzione è considerata la più sicura di tutte. Simile alla categoria precedente, si dovrebbe presumere che l'hardware possa essere rubato e portato online. Per questo motivo, è ancora una volta importante che questi sistemi includano livelli di controllo degli accessi correttamente implementati, come discusso in precedenza. Molti fornitori di HSM richiedono un quorum di smartcard fisiche da riunire prima che l'accesso alle chiavi possa essere sbloccato. Anche se il dispositivo non dispone di uno schermo, dovrebbe offrire agli utenti un modo per verificare i dettagli delle transazioni.

Poiché i wallet cold o airgapped sono la categoria più sicura, la maggior parte dei fondi gestiti dai big player vengono archiviati in questo modo. I principali servizi di vendita al dettaglio, come Coinbase, Gemini, Kraken e altri, nonché i servizi per utenti istituzionali come Anchorage, sono tra quelli che lo fanno. Molti di questi giocatori scelgono di avere un'altra linea di difesa sotto forma di backup e ripristino, nel caso in cui – il cielo non voglia – perdano l'accesso o le macchine vengano danneggiate, rubate o distrutte.

Backup e ripristino

Le chiavi di firma devono sempre essere sottoposte a backup dopo essere state crittografate. È fondamentale disporre della ridondanza sia delle chiavi di firma crittografate che delle chiavi di wrapping delle chiavi. I metodi per eseguire il backup di una chiave di firma sono diversi, ma si dovrebbero sempre preferire soluzioni hardware native.

Per i portafogli hardware, i backup di solito implicano una frase seme di 12 parole in chiaro da cui derivano le chiavi private. Questa frase seme dovrebbe essere archiviata in modo non digitale (pensa a carta, metallo) e nel modo più sicuro disponibile (un caveau fisico a casa, all'interno di un caveau di una banca). La frase può essere suddivisa in parti geograficamente distribuite per evitare un facile compromesso dell'intero segreto. (Le persone a volte spiegano questo approccio facendo riferimento agli horcrux immaginari che i maghi oscuri usano efficacemente per "sostenere" le loro anime in Harry Potter.)

Molti HSM gestiscono in modo nativo alcune delle sfide relative al backup e al ripristino. Quelli standard hanno meccanismi in grado di esportare chiavi che sono, per impostazione predefinita, crittografate con controlli di accesso. Se i controlli di accesso sono soddisfatti, le chiavi possono essere importate in altri HSM. Utilmente, è anche possibile eseguire il provisioning di flotte di HSM con una chiave di crittografia comune, derivata da un quorum di smartcard. Il disaccoppiamento dell'hardware dai materiali chiave in questo modo consente di evitare singoli punti di errore.

Infine, i fattori umani devono essere affrontati. I meccanismi di risanamento dovrebbero essere in grado di resistere all'indisponibilità temporanea o permanente di qualsiasi persona coinvolta nelle operazioni di gestione dei conti. Gli individui dovrebbero assicurarsi di fornire modi ai familiari stretti o ad altre parti fidate per recuperare le chiavi in ​​caso di morte o altre emergenze. Le operazioni di gruppo, nel frattempo, dovrebbero definire un quorum, ad esempio 2 su 3 o 3 su 5, che può funzionare ragionevolmente nonostante eventi della vita, viaggi, malattie o incidenti.

Sicurezza del portafoglio di utilizzo delle chiavi

Dopo che le chiavi sono state generate e archiviate, possono essere utilizzate per creare firme digitali che autorizzano le transazioni. Maggiore è il numero di componenti software e hardware nel mix, maggiore è il rischio. Per ridurre il rischio, i portafogli dovrebbero attenersi alle seguenti linee guida per l'autorizzazione e l'autenticazione.

  • Fidarsi ma verificare

I portafogli dovrebbero richiedere l'autenticazione. In altre parole, dovrebbero verificare che gli utenti siano chi dicono di essere e che solo le parti autorizzate possano accedere ai contenuti del portafoglio. Le protezioni più comuni qui sono codici PIN o passphrase. Come sempre, questi dovrebbero essere sufficientemente lunghi e complessi, utilizzando molti tipi diversi di caratteri, per essere efficaci al massimo. Forme di autenticazione più avanzate possono includere dati biometrici o approvazioni basate sulla crittografia a chiave pubblica, come firme crittografiche da più altri dispositivi protetti.

  • Non lanciare le tue criptovalute (di nuovo!)

I portafogli dovrebbero utilizzare librerie di crittografia consolidate. Fai qualche ricerca per assicurarti che siano controllati e sicuri in modo da evitare la perdita di materiale delle chiavi o la perdita completa delle chiavi private. A complicare la questione, anche le librerie affidabili possono avere interfacce non sicure, come è successo di recente queste librerie Ed25519. Stai attento! 

  • Non riutilizzo

Una trappola per l'utilizzo delle chiavi ben studiata è il riutilizzo involontario di alcuni parametri della firma crittografica. Alcuni schemi di firma potrebbero richiedere a nonce che significa "numero usato una volta", un numero arbitrario pensato solo per essere usato, beh, una volta in un sistema. L'algoritmo di firma digitale a curva ellittica (ECDSA) è uno di questi schemi di firma che lo fa. Se un nonce viene riutilizzato con ECDSA, può portare a un compromesso chiave. Vari altri algoritmi non sono interessati, quindi, come al solito, assicurati che vengano utilizzate librerie crittografiche consolidate. (Alcune librerie crittografiche garantiscono nonce univoci eseguendo l'hashing dei dati delle transazioni, che includono altri dati univoci come i nonce dell'account.) Ma questo vettore di attacco è stato sfruttato in precedenza in hack di alto profilo al di fuori del web3, come questo 2010 Sony PlayStation 3 hackeraggio.

  • Una chiave per scopo

Un'altra best practice consiste nell'evitare il riutilizzo di una chiave per più di un singolo scopo. Ad esempio, devono essere conservate chiavi separate per la crittografia e la firma. Ciò segue il principio di “privilegio minimo” in caso di compromissione, il che significa che l'accesso a qualsiasi risorsa, informazione o operazione dovrebbe essere limitato solo alle parti o al codice che lo richiedono assolutamente per il funzionamento del sistema. Il principio del "privilegio minimo" può, se implementato correttamente, limitare drasticamente il raggio di esplosione di un attacco riuscito. Chiavi diverse avranno requisiti diversi per i backup e la gestione degli accessi a seconda del loro scopo. Nel contesto di web3, è una buona pratica separare le chiavi e le frasi iniziali tra asset e portafogli, in modo che la compromissione di un account non influisca su nessun altro.

Conclusione

La natura di custodia o non di custodia della proprietà delle chiavi non è così in bianco e nero come il pensiero convenzionale vorrebbe far credere. La situazione è complicata dalle molte parti mobili coinvolte nella gestione delle chiavi, dalla generazione delle chiavi all'archiviazione fino all'utilizzo. Ogni pezzo di hardware o software lungo la catena introduce rischi che espongono anche opzioni di portafoglio presumibilmente non detentive a rischi di tipo custodia. 

Per il futuro, prevediamo che venga svolto un ulteriore lavoro di sviluppo per proteggere i portafogli dagli attacchi e per mitigare i rischi discussi sopra. Le aree di miglioramento includono:

  • Librerie di gestione delle chiavi open source e sicure condivise e librerie di firma delle transazioni su sistemi operativi mobili e desktop
  • Framework di approvazione delle transazioni open source condivisi

In particolare, saremmo particolarmente entusiasti di vedere lo sviluppo per condivisi e open-source:

  • Librerie di generazione di chiavi per implementare la sicurezza migliore tra i diversi backend di archiviazione (crittografati su disco, hardware sicuro, ecc.)
  • Librerie per la gestione delle chiavi e la firma delle transazioni per sistemi operativi mobili e desktop
  • Framework per i flussi di approvazione delle transazioni che implementano una forte verifica dei fattori come la biometria, le approvazioni basate su PKI, il recupero dell'autorizzazione, ecc.

L'elenco di cui sopra non è esaustivo, ma è un buon punto di partenza. Tutto questo per dire che la situazione è più complicata di quanto indichi lo slogan “not your keys, not your crypto”. Il possesso delle chiavi è una questione complicata date le numerose parti e fasi che interagiscono dalla generazione e dall'archiviazione fino all'utilizzo. 

Se stai già lavorando a un progetto che affronta uno dei precedenti o saresti interessato a farlo, contattaci! Attendiamo con impazienza ulteriori progressi su questi fronti.

***

Editore: Robert Hackett, @rhhackett

***

Le opinioni qui espresse sono quelle del personale di AH Capital Management, LLC ("a16z") citato e non sono le opinioni di a16z o delle sue affiliate. Alcune informazioni qui contenute sono state ottenute da fonti di terze parti, incluse società in portafoglio di fondi gestiti da a16z. Sebbene tratti da fonti ritenute affidabili, a16z non ha verificato in modo indipendente tali informazioni e non fornisce dichiarazioni sull'accuratezza attuale o duratura delle informazioni o sulla sua adeguatezza per una determinata situazione. Inoltre, questo contenuto può includere pubblicità di terze parti; a16z non ha esaminato tali annunci pubblicitari e non approva alcun contenuto pubblicitario in essi contenuto. 

Questo contenuto viene fornito solo a scopo informativo e non deve essere considerato come consulenza legale, commerciale, di investimento o fiscale. Dovresti consultare i tuoi consulenti in merito a tali questioni. I riferimenti a qualsiasi titolo o risorsa digitale sono solo a scopo illustrativo e non costituiscono una raccomandazione di investimento o un'offerta per fornire servizi di consulenza in materia di investimenti. Inoltre, questo contenuto non è diretto né destinato all'uso da parte di investitori o potenziali investitori e non può in alcun caso essere invocato quando si decide di investire in qualsiasi fondo gestito da a16z. (Un'offerta per investire in un fondo a16z sarà fatta solo dal memorandum di collocamento privato, dal contratto di sottoscrizione e da altra documentazione pertinente di tale fondo e dovrebbe essere letta nella sua interezza.) Eventuali investimenti o società in portafoglio menzionati, citati o descritti non sono rappresentativi di tutti gli investimenti in veicoli gestiti da a16z, e non si può garantire che gli investimenti saranno redditizi o che altri investimenti effettuati in futuro avranno caratteristiche o risultati simili. Un elenco degli investimenti effettuati da fondi gestiti da Andreessen Horowitz (esclusi gli investimenti per i quali l'emittente non ha autorizzato a16z a divulgare pubblicamente e gli investimenti non annunciati in asset digitali quotati in borsa) è disponibile all'indirizzo https://a16z.com/investments /.

Grafici e grafici forniti all'interno sono esclusivamente a scopo informativo e non dovrebbero essere presi in considerazione quando si prende una decisione di investimento. I rendimenti passati non sono indicativi di risultati futuri. Il contenuto parla solo a partire dalla data indicata. Eventuali proiezioni, stime, previsioni, obiettivi, prospettive e/o opinioni espresse in questi materiali sono soggette a modifiche senza preavviso e possono differire o essere contrarie alle opinioni espresse da altri. Si prega di consultare https://a16z.com/disclosures per ulteriori informazioni importanti.

Timestamp:

Di più da Andreessen Horowitz