Vérifier le téléchargement d'un wallet : sommes de contrôle, signatures et builds reproductibles
Lorsque vous installez un wallet, vous faites confiance au fait que le fichier présent sur votre ordinateur est exactement le logiciel publié par ses développeurs, et non une copie modifiée provenant d'un site compromis, d'une fausse page de téléchargement ou d'un build altéré. Pour la plupart des gens, installer depuis la boutique officielle suffit. Mais pour qui préfère vérifier plutôt que faire confiance, les wallets open source peuvent offrir trois outils de plus en plus solides : les sommes de contrôle, les signatures et les builds reproductibles.
Voici ce que prouve chacun d'eux, et comment les utiliser avec SSP Wallet.
Sommes de contrôle : est-ce le même fichier ?
Une somme de contrôle est l'empreinte d'un fichier, produite par une fonction de hachage comme SHA-256. Modifiez un seul octet et l'empreinte change complètement. Si la somme de contrôle du fichier téléchargé correspond à celle publiée par les développeurs, vous avez le même fichier.
Sous macOS ou Linux, vous pouvez la calculer dans un terminal :
shasum -a 256 ssp-wallet-chrome-v2.1.3.zip
Une somme de contrôle seule a une faiblesse : si un attaquant contrôle la page de téléchargement, il peut remplacer à la fois le fichier et la somme de contrôle publiée. C'est pourquoi l'étape suivante est importante.
Signatures : les développeurs ont-ils publié ceci ?
Une signature prouve qui a publié les sommes de contrôle. Les développeurs signent le fichier des sommes de contrôle avec une clé privée, et toute personne disposant de la clé publique correspondante peut vérifier cette signature. Un attaquant qui modifie le fichier ou les sommes de contrôle ne peut pas produire de signature valide sans cette clé privée.
Le seul point sur lequel vous ne devez pas vous tromper, c'est la clé publique elle-même. Obtenez-la depuis une source officielle du projet, vérifiez son empreinte sur plus d'un canal officiel, puis utilisez la même clé pour chaque version.
Builds reproductibles : ce fichier a-t-il vraiment été compilé à partir du code publié ?
Les signatures prouvent qui a publié un fichier, pas ce qu'il contient. La machine de compilation d'un développeur pourrait être compromise et signer de bonne foi un résultat malveillant.
Les builds reproductibles, ou déterministes, comblent cette lacune. Le processus de compilation est figé de sorte que le même code source produise toujours un fichier identique octet par octet, sur n'importe quelle machine. Chacun peut recompiler une version à partir du code public et comparer les sommes de contrôle. Si elles correspondent, le fichier publié contient exactement ce que dit le code source, et rien d'autre. Attaques de la chaîne d'approvisionnement et builds déterministes explique pourquoi c'est si important pour les wallets.
Vérifier SSP Wallet
Les versions de SSP Wallet sur GitHub (RunOnFlux/ssp-wallet) sont compilées de manière déterministe pour Chrome et Firefox et incluent deux fichiers supplémentaires : SHA256SUMS, qui liste la somme de contrôle de chaque paquet, et SHA256SUMS.asc, une signature GPG de cette liste.
1. Téléchargez les fichiers de la version. Depuis la page de la version, téléchargez le paquet correspondant à votre navigateur, nommé par exemple ssp-wallet-chrome-v2.1.3.zip ou ssp-wallet-firefox-v2.1.3.zip, ainsi que SHA256SUMS et SHA256SUMS.asc, dans un même dossier.
2. Vérifiez la signature. Une fois la clé publique de signature des versions SSP importée dans GPG :
gpg --verify SHA256SUMS.asc SHA256SUMS
GPG doit indiquer une signature valide provenant de la clé attendue. S'il signale une mauvaise signature ou une clé inconnue, arrêtez-vous.
3. Vérifiez les fichiers par rapport à la liste.
sha256sum -c SHA256SUMS
Sous macOS, shasum -a 256 -c SHA256SUMS fait la même chose. Chaque fichier téléchargé doit afficher OK. La liste couvre à la fois les paquets Chrome et Firefox ; si vous n'en avez téléchargé qu'un, ajoutez --ignore-missing pour que l'autre ne soit pas signalé comme absent.
4. Facultatif : compilez-le vous-même. Clonez le dépôt au tag de la version et lancez le build déterministe :
git clone https://github.com/RunOnFlux/ssp-wallet.git
cd ssp-wallet
git checkout <release-tag>
yarn build:deterministic
Le build s'exécute dans un environnement Docker figé et écrit son propre SHA256SUMS. Si vos sommes de contrôle correspondent à celles publiées, vous avez confirmé de manière indépendante que la version a été compilée à partir de ce code source.
Et les boutiques des navigateurs ?
La plupart des gens installent SSP Wallet depuis le Chrome Web Store ou Firefox Add-ons, ce qui est un choix raisonnable : les installations depuis une boutique se mettent à jour automatiquement et les boutiques ont leurs propres processus de vérification. Les sommes de contrôle ci-dessus concernent les paquets des versions publiées sur GitHub. Si vous installez depuis une boutique, les vérifications les plus importantes sont plus simples : avoir atteint la fiche depuis le site officiel, et que l'éditeur corresponde. Repérer les fausses applications de wallet détaille ces étapes, et l'hygiène des extensions de navigateur explique comment garder ensuite votre navigateur sûr.
Le résumé honnête
Une somme de contrôle prouve que vous avez le même fichier ; une signature prouve qui l'a publié ; un build reproductible prouve que le fichier provient du code publié. Chaque étape supprime un type de confiance différent.
La plupart des gens installeront depuis la boutique officielle, et c'est très bien. Si vous voulez vérifier par vous-même, les versions de SSP Wallet vous donnent les trois outils : une liste de sommes de contrôle signée, une vérification en une ligne et un build que vous pouvez reproduire octet par octet.
