Sécurité du portefeuille : le sophisme de la « non-dépositaire »

L'expression couramment citée "pas vos clés, pas votre crypto" traduit la philosophie puriste de la gestion des clés cryptographiques. Dans ce modèle de sécurité de portefeuille, seul un individu (ou un groupe via "multisig") a un contrôle direct et exclusif sur ses propres clés privées - et, par conséquent, a la véritable propriété de ses actifs cryptographiques. Les portefeuilles cryptographiques adhérant à cette approche stricte sont appelés "non dépositaires", ce qui signifie qu'aucune partie extérieure n'a accès aux clés.

Sauf que pas si vite. La situation n'est pas si simple. Un certain nombre de hacks de portefeuille « non dépositaires » très médiatisés, y compris le Hack de portefeuille Slope qui a compromis plus de 8,000 XNUMX comptes en août, le Hack du portefeuille Trinity qui a perdu plus de 2 millions de dollars de jetons IOTA en 2020, le Piratage de portefeuille parité qui a permis à un attaquant de voler 150,000 2017 ETH en XNUMX, ainsi que des découvertes de divers vulnérabilités du portefeuille matériel, et d'autres incidents - sape la distinction conventionnelle entre les portefeuilles dépositaires et non dépositaires. Dans bon nombre de ces cas, les victimes qui pensaient utiliser un portefeuille non privatif ont découvert que les attaquants étaient capables de détourner leurs clés convoitées. Une contradiction, non ?

En effet, l'histoire est plus complexe qu'un slogan ne peut le saisir. Les portefeuilles non dépositaires ne donnent pas vraiment aux utilisateurs le contrôle total de leurs clés. C'est parce que les portefeuilles sont généralement créé par, et exploité via, le logiciel ou le matériel de quelqu'un d'autre. Les utilisateurs font constamment confiance à d'autres personnes, produits et programmes informatiques. Ils acceptent d'utiliser des interfaces de ligne de commande blockchain, des logiciels et des appareils de portefeuille, des plates-formes centralisées, code de contrat intelligent, applications décentralisées et tous les différents portefeuilles intégrations de connexion entre les deux. Chaque point de contact ajoute un risque ; la somme de toutes ces pièces imbriquées brise l'illusion du portefeuille non dépositaire.

La tutelle est, en réalité, non-binaire. Ce qui pourrait à première vue sembler non privatif de liberté peut en réalité impliquer de nombreux éléments de détention dont la fiabilité est souvent tenue pour acquise. La dichotomie traditionnelle – gardien contre non gardien – est fausse. 

Au lieu de cela, il vaut mieux considérer les portefeuilles avec plus de nuances. Les questions clés à se poser sont les suivantes : quelle taille de surface d'attaque suis-je à l'aise d'accepter et combien de responsabilités suis-je prêt à assumer dans ma quête pour éliminer la confiance envers les tiers ? En général, la gestion des clés - le fondement de la sécurité du portefeuille - peut être divisée en trois domaines, chacun ayant des opportunités uniques d'exposition. Les sous-catégories sont les suivantes :

1. Génération de clés (création de clés cryptographiques)

2. Stockage des clés (sécurisation des clés au repos)

3. Utilisation des clés (mettre les clés au travail)

Cet aperçu est destiné à aider les utilisateurs de web3 à mieux comprendre les subtilités impliquées dans la sécurisation de leurs actifs au moyen de la rubrique ci-dessus. De plus, notre objectif est d'aider les ingénieurs à identifier et à consolider les points de défaillance fréquents dans le développement de portefeuilles. Nous espérons que l'application de ce guide - issu de nos nombreuses années d'expérience combinée dans la création de systèmes de cryptographie et de sécurité sur Docker, Anchorage, Facebook et a16z crypto - aidera les gens à éviter les problèmes de sécurité, qu'ils interagissent avec, participent ou construire la technologie web3.

Ci-dessous, nous couvrons les caractéristiques et les pièges communs des plates-formes de sécurité et de conservation des portefeuilles cryptographiques telles qu'elles existent aujourd'hui. Nous couvrons également les domaines qui, selon nous, nécessitent le plus d'attention et de développement dans les mois et les années à venir pour améliorer la sécurité des expériences Web3 des utilisateurs.

Sécurité du portefeuille de génération de clés

Toute discussion sur la sécurité du portefeuille doit commencer par la génération de clés, le processus de création de clés cryptographiques. Que le portefeuille soit considéré comme gardien ou non gardien, les propriétés de sécurité de l'étape de génération de clé sont primordiales pour la sécurité des clés par la suite. Lors de la génération de clé, il y a trois préoccupations primordiales à garder à l'esprit : utiliser un code fiable, implémenter le code correctement et gérer en toute sécurité la sortie.

Si vous n'êtes pas un expert en cryptographie, il peut être difficile de vérifier que tous les facteurs suivants sont respectés. Vérifiez si vous pouvez accéder à un rapport d'audit de confiance, que certains fournisseurs de portefeuille publient sur leurs sites Web officiels ou leurs référentiels Github. Au lieu de cela, faites vos propres recherches pour essayer de déterminer s'il y a une entreprise de bonne réputation derrière le portefeuille. Si les informations sont rares, une activité importante des utilisateurs et des développeurs peut être le prochain indicateur de réputation.

Suivez ces directives pour réduire votre exposition aux risques. Si un portefeuille échoue aux vérifications ci-dessous, fuyez !

• Utilisez des portefeuilles qui ne roulent pas leur propre crypto

Les cryptographes ont un dicton : "ne lancez pas votre propre crypto". L'essentiel est similaire à l'adage "ne réinventez pas la roue". La roue est bien telle quelle et toute tentative de reconstruire une à partir de zéro entraînera probablement un produit moins bon. Il en va de même pour la cryptographie, une science difficile à obtenir exactement. Le code composant un wallet doit avoir la réputation de bien fonctionner. Choisir un logiciel mal écrit – ou tenter de développer sa propre alternative de novo – peut entraîner des incidents tels que la fuite de clés ou la révélation d'informations secrètes à des tiers non autorisés. C'est ce qui se cache derrière une vulnérabilité récemment exploitée dans Outil d'adresse personnalisée de Profanity. Avant toute chose, il doit être clair que le portefeuille en question utilise une bibliothèque et un processus de génération de clés audités et réputés.

• Utilisez des portefeuilles qui mesurent deux fois et coupez encore et encore

Même si le code utilise des bibliothèques de cryptographie réputées, il doit toujours être correctement intégré. Les logiciels vérifiés configurent généralement les paramètres corrects par défaut, mais il peut y avoir des lacunes dans l'exécution. Par exemple, une forte source d'entropie, ou une dose d'aléatoire mathématique, est nécessaire pour rendre les clés à générer imprévisibles et, par conséquent, plus sûres. Pour certains processus de génération de clés, comme pour de nombreux algorithmes de calcul multipartite (MPC), dans lesquels de nombreuses clés distinctes - ou fragments, fragments de clés - doivent être générées et coordonnées, le portefeuille doit suivre le protocole précis spécifié par le algorithme. L'algorithme peut également nécessiter plusieurs cycles de calcul ainsi que des clés de rafraîchissement, que le portefeuille doit intégrer correctement pour maintenir la sécurité des fonds.

• Utilisez un portefeuille qui peut garder des secrets

La phase finale du processus de génération de clé implique le fonctionnement et la sortie réels du logiciel. Sachez où les clés sont générées et sous quelle forme.

Idéalement, les clés doivent être générées dans un matériel isolé et les informations doivent être cryptées avec un algorithme réputé. Un exemple de norme faible à éviter est Data Encryption Standard, ou DES, qui est aujourd'hui considéré comme cassé. Les clés laissées en clair - en particulier en mémoire, sur disque ou dans la zone médiane entre ces deux endroits appelés "échange" - constituent un risque majeur pour la sécurité. En général, le matériel de clé ne doit pas quitter le matériel sur lequel il est généré et ne doit pas s'échapper sur des réseaux accessibles par d'autres. (C'est-à-dire, à moins que le matériel de clé ne soit crypté, auquel cas la clé de cryptage doit également être sécurisée.)

Les clés de Slope, le portefeuille qui s'est fait pirater cet été, ont été enregistrés en clair sur des serveurs externes après avoir été générés. C'est le genre de faille de sécurité qui aurait pu apparaître lors d'un audit ou d'une implémentation open source du code. Les portefeuilles qui manquent de transparence - avec un code source fermé, aucun audit de sécurité tiers disponible pour le public - devraient déclencher des signaux d'alarme. 

Sécurité du portefeuille de stockage des clés

Une fois les clés générées, ils devront être cachés quelque part - jamais en clair, toujours cryptés. Mais simplement posséder l'appareil sur lequel les clés sont stockées n'équivaut pas nécessairement à la propriété et au contrôle des clés. De nombreux facteurs tels que la sécurité de la chaîne d'approvisionnement de l'appareil, le degré de connexion de l'appareil et les autres composants avec lesquels l'appareil interagit doivent être pris en compte. De plus, chaque méthode de stockage a son propre ensemble de compromis entre la sécurité, l'accessibilité, la maintenabilité et la convivialité.

Ci-dessous, nous décomposons les catégories les plus courantes en fonction de leur niveau de risque perçu associé. 

Risque plus élevé : portefeuilles "chauds"

Le concept n'a pas grand-chose à voir avec la température. En ce qui concerne les options de stockage de clés, un portefeuille est considéré comme "chaud" s'il est connecté à Internet. Un portefeuille est considéré comme "froid", en revanche, s'il est hors ligne et isolé. Toutes choses étant égales par ailleurs, les portefeuilles froids sont plus sûrs que les portefeuilles chauds, mais ils sont également plus difficiles d'accès et d'utilisation. Un portefeuille connecté à n'importe quel réseau est plus susceptible d'être piraté car il offre aux attaquants plus de chances d'accéder pour découvrir et exploiter les vulnérabilités.

Les portefeuilles chauds peuvent prendre plusieurs formes.

• Logiciels connectés : bases de données en ligne, mémoire d'application de téléphone ou de serveur Web, extensions de navigateur

Ce sont les options les plus risquées. Ici, le logiciel du portefeuille, dépositaire ou non, a un accès direct aux clés - tout en étant connecté à l'internet extérieur. Les clés doivent idéalement être chiffrées, et l'autre jeu de clés utilisé pour les chiffrer doit être stocké dans un système de gestion de clés (KMS) dédié avec des contrôles d'accès très restreints, tels qu'un trousseau de système d'exploitation ou un système de gestion de clés cloud.

Pour les portefeuilles actifs logiciels, il est essentiel d'isoler la gestion et l'autorisation des clés du reste des composants logiciels. Des problèmes peuvent survenir dans la journalisation, la gestion des erreurs et la gestion de la mémoire (en particulier basée sur le tas, où les clés peuvent ne pas être correctement « mises à zéro » ou effacées), qui peuvent toutes divulguer par erreur des mots de passe, des clés de chiffrement, des clés de signature ou d'autres éléments sensibles. matériel cryptographique. Lorsque cela se produit, les intrus peuvent obtenir un accès non autorisé via des applications connectées ou des serveurs Web, des attaques par canal auxiliaire ou des menaces internes.

Quelle que soit la manière dont un service s'étiquette, si les clés de signature ne sont pas chiffrées à tout moment dans la mémoire du système en ligne, le modèle doit être considéré comme un portefeuille logiciel à chaud. (Même si les clés sont ensuite stockées au repos dans une enclave sécurisée.)

• Matériel connecté : appareils dédiés, enclaves sécurisées mobiles, modules de sécurité matériels en ligne (HSM)

Le matériel connecté est généralement considéré comme moins risqué que les logiciels connectés, mais il n'est toujours pas aussi sécurisé que le stockage à froid. Dans le matériel connecté, les clés sont générées et ne vivent qu'à l'intérieur de dispositifs matériels à usage spécial. Ceux-ci peuvent ensuite être connectés à des réseaux internes ou publics. Ces appareils assument généralement plusieurs responsabilités liées à la gestion des clés, y compris la sécurité pour la génération, la signature et le stockage des clés.

Le matériel connecté se décline en plusieurs variétés. Il existe des portefeuilles matériels, tels que les appareils Trezor et Ledger, que les utilisateurs de crypto légèrement plus sophistiqués utilisent couramment. (Beaucoup plus de personnes devraient utiliser ces appareils, car ils sont beaucoup plus sûrs que d'utiliser uniquement des logiciels connectés.) Il existe également des modules de sécurité matériels, ou HSM, qui sont couramment utilisés dans des environnements professionnels plus traditionnels, tels que ceux qui gèrent le traitement de données sensibles. , comme les paiements par carte de crédit.

Les appareils ne sont aussi sûrs que la chaîne d'approvisionnement qui les a produits et configurés. Lorsque vous considérez le matériel connecté, demandez-vous : Quelle est la probabilité que les appareils - ou le micrologiciel - aient été altérés avant d'entrer en votre possession ? Pour réduire ce risque, il est préférable d'acheter des appareils directement auprès de fournisseurs de confiance. Faites-les expédier directement de la source. Assurez-vous que les emballages ne semblent pas compromis - pas de déchirures, de déchirures, de sceaux brisés, etc. - ce qui pourrait indiquer une altération pendant le transport. Il est également conseillé de vérifier la version et la configuration du micrologiciel avant utilisation. Les étapes à suivre varient en fonction du matériel, mais toutes doivent fournir des instructions.

Bien sûr, il y a toujours la possibilité qu'un portefeuille matériel soit plus tard volé ou accédé par une partie non autorisée. Compte tenu de ces menaces, il est important de s'assurer que les portefeuilles matériels disposent également de couches de contrôle d'accès sécurisées - des garanties garantissant qu'ils ne se contentent pas de signer aveuglément toutes les transactions. Les contrôles peuvent inclure des exigences de mot de passe, des invites demandant une autorisation explicite pour chaque étape d'une transaction et des résumés en anglais simple décrivant ce que les transactions sont en train de faire. De plus, la plupart des portefeuilles matériels prennent en charge le chiffrement à clé privée, également appelé « emballage de clé ». Mieux encore, les portefeuilles sécurisés ne permettront pas d'exporter les clés sous forme de texte brut, même si on le souhaite.

C'est le niveau de sécurité requis pour vraiment protéger les actifs cryptographiques.

Moins risqué : les portefeuilles « froids »

Moins de chaleur, moins de risques. Les portefeuilles froids sont, toutes choses étant égales par ailleurs, généralement considérés comme plus sûrs que les portefeuilles chauds, bien qu'ils soient également généralement moins utilisables. Les portefeuilles froids sont communément appelés portefeuilles "à vide", ce qui signifie qu'ils n'ont aucun lien avec un réseau interne ou public.

La solitude est une vertu dans ce cas. L'espace aérien implique la mise en œuvre de mesures rigoureuses d'isolement physique et d'autorisation. Ces mesures peuvent inclure l'utilisation de cages de Faraday (boucliers qui bloquent les signaux sans fil), l'accès biométrique (comme les scanners d'empreintes digitales ou d'iris), les détecteurs de mouvement (pour déclencher des alarmes en cas d'utilisation non autorisée) et les SCIF ou les installations d'information à compartiments sensibles (spécial domaines de traitement des informations classifiées).

Examinons plus en détail certaines options de portefeuille froid.

• Logiciel Airgrapped : application serveur hors ligne

Parce qu'un attaquant peut voler ou mettre une machine en ligne à tout moment, les portefeuilles froids doivent être conçus avec des systèmes de sécurité qui résistent même s'ils sont mis en ligne. Les clés doivent être divisées en fragments de clé - nécessitant que les pièces soient réunies pour être rendues utilisables - via une méthode standard, telle que le partage secret de Shamir ou le calcul multipartite. Le matériel à usage spécial, tel que les HSM, est fortement recommandé par rapport aux logiciels connectés car ils offrent généralement plus de contrôles.

• Matériel Airgrapped : portefeuille matériel hors ligne, module de sécurité matériel hors ligne (HSM)

Cette solution est considérée comme la plus sûre de toutes. Semblable à la catégorie précédente, il faut supposer que le matériel peut être volé et mis en ligne. Pour cette raison, il est à nouveau important que ces systèmes incluent des couches de contrôle d'accès correctement implémentées, comme indiqué précédemment. De nombreux fournisseurs de HSM exigent qu'un quorum de cartes à puce physiques soit réuni avant que l'accès aux clés puisse être déverrouillé. Même si l'appareil ne dispose pas d'un écran d'affichage, il devrait offrir aux utilisateurs un moyen de vérifier les détails des transactions.

Parce que les portefeuilles froids ou à vide sont la catégorie la plus sûre, la plupart des fonds gérés par les grands acteurs sont stockés de cette manière. Les principaux services de vente au détail, tels que Coinbase, Gemini, Kraken et autres, ainsi que les services destinés aux utilisateurs institutionnels tels qu'Anchorage, font partie de ceux qui le font. Beaucoup de ces joueurs choisissent d'avoir une autre ligne de défense sous la forme de sauvegardes et de récupération, juste au cas où - Dieu nous en préserve - ils perdraient l'accès, ou les machines seraient corrompues, volées ou détruites.

Sauvegardes et restauration

Les clés de signature doivent toujours être sauvegardées après avoir été chiffrées. Il est essentiel d'avoir une redondance des clés de signature chiffrées et des clés d'encapsulation des clés. Les méthodes de sauvegarde d'une clé de signature diffèrent, mais il faut toujours préférer les solutions matérielles natives.

Pour les portefeuilles matériels, les sauvegardes impliquent généralement une phrase de départ en texte clair de 12 mots à partir de laquelle les clés privées sont dérivées. Cette phrase de départ doit être stockée de manière non numérique (pensez au papier, au métal) et de la manière la plus sécurisée disponible (un coffre-fort physique à la maison, à l'intérieur d'un coffre-fort de banque). La phrase peut être divisée en parties réparties géographiquement pour éviter de compromettre facilement l'intégralité du secret. (Les gens expliquent parfois cette approche en faisant référence aux horcruxes fictifs que les sorciers noirs utilisent efficacement pour "sauvegarder" leurs âmes dans Harry Potter.)

De nombreux HSM gèrent nativement certains des défis liés à la sauvegarde et à la restauration. Les standards ont des mécanismes qui peuvent exporter des clés qui sont, par défaut, cryptées avec des contrôles d'accès. Si les contrôles d'accès sont satisfaits, les clés peuvent alors être importées dans d'autres HSM. Utilement, les flottes de HSM peuvent également être provisionnées avec une clé de chiffrement commune, dérivée d'un quorum de cartes à puce. Le découplage du matériel des matériaux clés de cette manière permet d'éviter les points de défaillance uniques.

Enfin, les facteurs humains doivent être pris en compte. Les mécanismes de récupération doivent pouvoir résister à l'indisponibilité temporaire ou permanente de toute personne impliquée dans les opérations de gestion de compte. Les particuliers doivent s'assurer de fournir aux membres de la famille proche ou à d'autres parties de confiance des moyens de récupérer les clés en cas de décès ou d'autres urgences. Les opérations de groupe, quant à elles, devraient définir un quorum - tel que 2 sur 3 ou 3 sur 5, disons - qui peut raisonnablement fonctionner malgré les événements de la vie, les voyages, la maladie ou les accidents.

Sécurité du portefeuille d'utilisation des clés

Une fois les clés générées et stockées, elles peuvent être utilisées pour créer des signatures numériques qui autorisent les transactions. Plus il y a de composants logiciels et matériels dans le mélange, plus le risque est grand. Pour réduire les risques, les portefeuilles doivent respecter les directives suivantes en matière d'autorisation et d'authentification.

• Faites confiance, mais vérifiez

Les portefeuilles doivent nécessiter une authentification. En d'autres termes, ils doivent vérifier que les utilisateurs sont bien ceux qu'ils prétendent être et que seules les parties autorisées peuvent accéder au contenu du portefeuille. Les protections les plus courantes ici sont les codes PIN ou les phrases secrètes. Comme toujours, ceux-ci doivent être suffisamment longs et complexes – utilisant de nombreux types de caractères différents – pour être efficaces au maximum. Des formes d'authentification plus avancées peuvent inclure des approbations basées sur la biométrie ou le cryptage à clé publique, telles que les signatures cryptographiques de plusieurs autres appareils sécurisés.

• Ne lancez pas votre propre crypto (encore !)

Les portefeuilles doivent utiliser des bibliothèques de cryptographie bien établies. Faites des recherches pour vous assurer qu'ils sont audités et sûrs afin d'éviter les fuites de matériel de clé ou la perte complète des clés privées. Pour compliquer les choses, même les bibliothèques de confiance peuvent avoir des interfaces non sécurisées, comme ce fut récemment le cas avec ces librairies Ed25519. Fais attention! 

• Nonce réutilisation

Un écueil d'utilisation de clé bien étudié est la réutilisation par inadvertance de certains paramètres de signature cryptographique. Certains schémas de signature peuvent nécessiter un Nonce signifiant "nombre utilisé une fois", un nombre arbitraire destiné à être utilisé, eh bien, une fois dans un système. L'algorithme de signature numérique à courbe elliptique (ECDSA) est l'un de ces schémas de signature qui le fait. Si un nonce est réutilisé avec ECDSA, cela peut entraîner une compromission de la clé. Divers autres algorithmes ne sont pas affectés, alors, comme d'habitude, assurez-vous que des bibliothèques cryptographiques bien établies sont utilisées. (Certaines bibliothèques cryptographiques garantissent des nonces uniques en hachant les données de transaction, qui incluent d'autres données uniques telles que les nonces de compte.) Mais ce vecteur d'attaque a déjà été exploité dans des hacks de haut niveau en dehors de web3, comme ce 2010 Piratage Sony PlayStation 3.

• Une clé par objectif

Une autre bonne pratique consiste à éviter de réutiliser une clé à plusieurs fins. Des clés distinctes doivent être conservées pour le chiffrement et la signature, par exemple. Cela suit le principe de «moindre privilège" en cas de compromission, ce qui signifie que l'accès à tout actif, information ou opération doit être limité uniquement aux parties ou au code qui en ont absolument besoin pour que le système fonctionne. Le principe du « moindre privilège » peut, lorsqu'il est correctement mis en œuvre, limiter considérablement le rayon d'explosion d'une attaque réussie. Différentes clés auront des exigences différentes pour les sauvegardes et la gestion des accès en fonction de leur objectif. Dans le contexte du Web3, il est recommandé de séparer les clés et les phrases de départ entre les actifs et les portefeuilles, afin que la compromission d'un compte n'affecte aucun autre.

Conclusion

La nature dépositaire ou non dépositaire de la propriété des clés n'est pas si noire et blanche que la pensée conventionnelle voudrait le faire croire. La situation est compliquée par les nombreuses pièces mobiles impliquées dans la gestion des clés - de la génération des clés au stockage en passant par l'utilisation. Chaque élément matériel ou logiciel de la chaîne présente des risques qui exposent même les options de portefeuille supposées non privatives de liberté à des risques de type dépositaire. 

Pour l'avenir, nous nous attendons à ce que davantage de travaux de développement soient effectués pour sécuriser les portefeuilles contre les attaques et pour atténuer les risques évoqués ci-dessus. Les domaines d'amélioration comprennent :

• Bibliothèques de gestion de clés et de signature de transactions open source sécurisées partagées sur les systèmes d'exploitation mobiles et de bureau
• Cadres d'approbation des transactions open source partagés

Plus précisément, nous serions particulièrement ravis de voir le développement d'applications partagées et open source :

• Bibliothèques de génération de clés pour mettre en œuvre la meilleure sécurité de sa catégorie sur différents backends de stockage (chiffrés sur disque, matériel sécurisé, etc.)
• Bibliothèques de gestion des clés et de signature des transactions pour les systèmes d'exploitation mobiles et de bureau
• Cadres pour les flux d'approbation des transactions mettant en œuvre une vérification forte des facteurs tels que la biométrie, les approbations basées sur l'ICP, la récupération des autorisations, etc.

La liste ci-dessus n'est pas exhaustive, mais c'est un bon point de départ. Tout cela pour dire que la situation est plus compliquée que ne l'indique le slogan "pas vos clés, pas votre crypto". La possession des clés est une question délicate compte tenu des nombreuses parties et phases en interaction, de la génération et du stockage à l'utilisation. 

Si vous travaillez déjà sur un projet qui répond à l'un des points ci-dessus, ou si vous êtes intéressé à le faire, n'hésitez pas à nous contacter ! Nous attendons avec impatience de nouveaux progrès sur ces fronts.

***

Éditeur : Robert Hackett, @rhhackett

***

Les opinions exprimées ici sont celles du personnel individuel d'AH Capital Management, LLC (« a16z ») cité et ne sont pas les opinions d'a16z ou de ses sociétés affiliées. Certaines informations contenues ici ont été obtenues de sources tierces, y compris de sociétés de portefeuille de fonds gérés par a16z. Bien qu'elles proviennent de sources considérées comme fiables, a16z n'a pas vérifié ces informations de manière indépendante et ne fait aucune déclaration quant à l'exactitude actuelle ou durable des informations ou à leur pertinence dans une situation donnée. De plus, ce contenu peut inclure des publicités de tiers ; a16z n'a pas examiné ces publicités et n'approuve aucun contenu publicitaire qu'elles contiennent. 

Ce contenu est fourni à titre informatif uniquement et ne doit pas être considéré comme un conseil juridique, commercial, d'investissement ou fiscal. Vous devriez consulter vos propres conseillers sur ces questions. Les références à des titres ou à des actifs numériques sont uniquement à des fins d'illustration et ne constituent pas une recommandation d'investissement ou une offre de fournir des services de conseil en investissement. En outre, ce contenu n'est ni destiné ni destiné à être utilisé par des investisseurs ou des investisseurs potentiels, et ne peut en aucun cas être invoqué pour prendre une décision d'investir dans un fonds géré par a16z. (Une offre d'investissement dans un fonds a16z ne sera faite que par le mémorandum de placement privé, le contrat de souscription et toute autre documentation pertinente de ce fonds et doit être lu dans son intégralité.) Tous les investissements ou sociétés de portefeuille mentionnés, référencés ou décrits ne sont pas représentatifs de tous les investissements dans des véhicules gérés par a16z, et rien ne garantit que les investissements seront rentables ou que d'autres investissements réalisés à l'avenir auront des caractéristiques ou des résultats similaires. Une liste des investissements effectués par des fonds gérés par Andreessen Horowitz (à l'exclusion des investissements pour lesquels l'émetteur n'a pas autorisé a16z à divulguer publiquement ainsi que des investissements non annoncés dans des actifs numériques cotés en bourse) est disponible sur https://a16z.com/investments /.

Les tableaux et graphiques fournis ici sont uniquement à des fins d'information et ne doivent pas être utilisés pour prendre une décision d'investissement. Les performances passées ne représentent pas les résultats futurs. Le contenu ne parle qu'à la date indiquée. Toutes les projections, estimations, prévisions, objectifs, perspectives et/ou opinions exprimées dans ces documents sont susceptibles d'être modifiées sans préavis et peuvent différer ou être contraires aux opinions exprimées par d'autres. Veuillez consulter https://a16z.com/disclosures pour des informations supplémentaires importantes.