Design: Signature/Vérification du module WASM

Je crois que nous avons également besoin de l'équivalent au format texte, peut-être quelque chose comme : (signature ...) .

Pour CSP, la vérification de la signature pourrait être activée sur https ? Ou pensez-vous qu'il devrait être activé par défaut ?

Hmmm, "CSP et vérification": ce serait très tôt dans le processus. Nous aurions besoin d'une (ou de plusieurs) clé publique du serveur ou de toute autre instance pour vérification, et il doit s'agir d'une clé publique utilisant EC (courbe éclliptique).

S'il s'agissait d'un service basé sur HTTP(S), il serait nécessaire d'accéder à la clé publique correspondante (clé à courbe elliptique). Peut-être que la clé publique correspondante pourrait être intégrée en tant qu'attribut d'en-tête HTTP de la page Web qui charge les modules WASM.

Après avoir signé les modules WASM, ceux-ci pourraient être récupérés de n'importe quel endroit et vérifiés.

Y aurait-il une seule organisation (hébergeur) signant les fichiers WASM ou une page Web récupèrerait-elle les modules signés de plusieurs organisations/fournisseurs ?

En cas d'organisations multiples, soit en ajoutant le "ID d'organisation" à la signature elle-même, soit en définissant une sorte de SignerOrg en tant que section supplémentaire (taille fixe également). le processus peut ressembler à : attacher d'abord la section SignerOrg, puis signer les deux (module original-bytecode & signerorg-section)

il semble que le cas d'utilisation et le processus doivent être définis en premier ;)

J'aimerais mieux comprendre comment les mécanismes actuels de signature et de vérification du Web échouent, et comment la prise en charge de WebAssembly de première classe résoudrait ce problème. Plus précisément, le Web a HTTPS et l'intégrité des sous-ressources qui, bien que certainement pas parfaits, font déjà beaucoup pour nous.

Pourriez-vous expliquer en détail ce que vous voudriez corriger, et en quoi votre proposition ne présente pas les mêmes écueils ?

Eh bien, je peux essayer

Les signatures intégrées sont déjà utilisées pour les PDF, les binaires Win, les pilotes, les documents XML, etc.
À quoi pourraient servir les modules WebAssembly signés ?

Imagine seulement

• Application Web exécutant le code WebAssembly pour calculer les codes PIN bancaires.
• Applications Rust/C++ utilisant WebAssembly pour les moteurs d'exécution embarqués, évaluant les contrats de crypto-monnaie
• HSM-s utilisant le bytecode WebAssembly pour calculer les codes PIN dans le backend du serveur
• Appareils IoT dont le firmware est assemblé à l'aide de versions spécifiques de différents modules WebAssembly (Content Addressable Storage/Linking)

Dans ce dernier cas, la version du firmware des appareils IoT serait une liste de modules WebAssembly utilisant des versions spécifiques. Les appareils IoT pourraient diffuser leur version des modules WebAssembly à d'autres appareils du quartier (http://www.korhal.io/whitepaper.pdf). Aucun serveur de mise à jour central ne serait requis.

Dans tous ces cas, un transport TSL n'est pas suffisant pour établir la confiance, mais le code doit être signé afin que le destinataire puisse vérifier l'authenticité, l'intégrité tout au long de la chaîne d'approvisionnement, du développeur/fournisseur au navigateur Web ou à l'exécution. moteur.
La signature empêche la falsification des données au repos et sous l'aspect juridique. Non-répudiation pour le code critique de fonctionnement.

L'utilisation d'une signature détachée (par rapport à une signature intégrée dans le module WASM) serait plus complexe à gérer. La signature intégrée simplifierait la gestion tout au long de la chaîne d'approvisionnement du bytecode.

Je ne suis pas convaincu qu'il s'agisse d'un problème mieux résolu au niveau de WASM lui-même. Des signatures peuvent être ajoutées à toutes les données. Pourquoi auraient-ils besoin de faire partie de la langue elle-même ?

De plus, il me semble que vous pourriez être intéressé par la norme HTTP Origin-Signed Responses .

Triste d'entendre. Une partie du langage, car un wasm signé conserverait un fichier wasm valide ; ce ne serait donc pas une sorte de wrapper à supprimer avant l'analyse. Eh bien, grâce à l'existence de CustomSection, il est possible d'ajouter de telles structures. Juste, cela aurait été bien de le déplacer de "fonctionnalité personnalisée" à une "fonctionnalité standard".