Démonstration d'auto-mise à jour écrite en C++. Inclut les outils de chargement, de client, de serveur et de signature pour fournir en toute sécurité des mises à jour automatiques pour les applications de bureau Win32.
Les applications de bureau Win32 natives n'ont pas le luxe d'un gestionnaire de packages intégré au système pour gérer les mises à jour automatiques. Ce cadre fournit une démonstration pratique de la manière de fournir et de traiter les mises à jour de manière sécurisée et efficace.
Un système de mise à jour automatique doit satisfaire aux objectifs de sécurité en matière d’intégrité et d’authenticité. Ce framework utilise des clés RSA de 4 096 bits pour signer et vérifier la signature SHA-256 des données de mise à jour. La clé publique est intégrée dans le binaire du client pour vérification. En supposant que la livraison initiale du logiciel soit effectuée via une source fiable, les seuls émetteurs valides pour les mises à jour sont ceux ayant accès à la clé privée.
Les données de mise à jour sont transmises via UDP. Le principal facteur dans cette décision était de réduire la surcharge de mémoire du serveur due aux connexions TCP (avec une charge CPU réduite en prime). La surcharge de mémoire attendue est d’environ :
(Update File Size) + (Max Connections) * 80 bytes
Les données de mise à jour sont stockées directement en mémoire pour éviter d'accéder au disque. Le client et le serveur vérifient la propriété de l'adresse IP en échangeant des jetons cryptographiques 64 bits. Chaque connexion se voit attribuer une quantité limitée de bande passante réseau avant d'être limitée. Chaque adresse IP est limitée à un nombre maximum de connexions simultanées. Ces fonctionnalités atténuent un certain nombre d'attaques réseau courantes :
La prévention des attaques de l'homme du milieu repose sur les garanties d'authenticité du système de mise à jour.
Aucune fonction cryptographique lourde n'a besoin d'être exécutée sur le serveur (comme dans HTTPS) puisque la confidentialité n'est pas un objectif de sécurité pour les mises à jour logicielles : les données de mise à jour ne sont pas sensibles.
Aucun effort n'est fait du côté client pour limiter la vitesse de téléchargement. L'intégration dans votre application doit s'efforcer d'ajuster dynamiquement le taux d'envoi en fonction des paquets abandonnés et de la latence de connexion.
L'architecture du serveur de démonstration s'exécute sur un seul port/un seul thread. Plusieurs instances de serveur peuvent être exécutées par thread sur différents ports ou différents systèmes (la négociation se produisant au niveau d'un équilibreur de charge auquel le client se connecterait en premier (pour la livraison de mises à jour à grande échelle).
Les données de mise à jour sont envoyées telles quelles pour un seul fichier. Si vous avez besoin de prendre en charge plusieurs correctifs de fichiers, mises à jour delta ou compression, vous devez fournir un exécutable avec les utilitaires et les données nécessaires pour gérer ces fonctionnalités (et le dissocier du système de mise à jour lui-même).
Les garanties de sécurité ne sont valables que tant que la clé privée reste sécurisée. Aucune méthode de révocation de clé n'est fournie avec le framework (car elle nécessiterait une vérification externe et la confiance d'un autre fournisseur).
updater.sln
.Release
.client.dll
en update.dll
signtool.exe
pour générer pub.h
, pub.key
, pri.key
et update.sig
.public_key
dans client_updater.cpp
par le contenu du pub.h
généré.server.exe
et loader.exe
pour démontrer la mise à jour.