J'ai remarqué qu'Android s'ouvre automatiquement pour les nouvelles mises à jour et les correctifs.
Ces mises à jour sont-elles signées de manière à ce que l'appareil sache qu'elles proviennent de l'éditeur officiel et non d'un serveur pirate ?
Réponses
Trop de publicités?
MechMK1
Points
131
Les mises à jour sont-elles signées numériquement avant d'être expédiées ?
Oui, les mises à jour sont signées de manière cryptographique par l'éditeur. Cela permet de garantir l'intégrité de la mise à jour, à la fois contre la corruption involontaire pendant la transmission et contre la manipulation délibérée d'un attaquant.
Qui signe les mises à jour ? Est-ce Google ?
Cela dépend de qui publie les mises à jour pour votre téléphone. Si vous possédez un téléphone Nexus ou Pixel, la mise à jour est probablement publiée et signée par Google.
D'autres fabricants, comme Samsung par exemple, modifient Android avant de le livrer. Cela peut inclure leurs propres applications système, leurs propres lanceurs, etc. Dans ce cas, le fabricant est l'éditeur de la mise à jour et donc responsable de sa signature.
Mais n'est-ce pas Google qui développe Android ?
Ce n'est pas Google seul, c'est la OHA - Il se trouve que Google est leur membre le plus important. De plus, Android est Source ouverte Les contributions proviennent donc de nombreuses entreprises et personnes différentes, et pas seulement de Google.
QUI SIGNE LES COMPOSANTS DE LA PLATEFORME Android ?
Comme l'explique très bien l'article de @MechMK1 réponse Google est le principal contributeur au développement de l'AOSP. Mais AOSP n'est pas le seul logiciel présent sur les appareils Android, il existe un certain nombre de morceaux de code spécifiques au matériel. Avant tout, il y a le noyau (basé sur l'AOSP). noyau commun source), mais qui doit être à source ouverte en raison de la GPL, de sorte que les fournisseurs d'OEM/SoC sont tenus de publier le code source. Cependant, d'autres parties, en particulier les HAL de l'espace utilisateur qui comprennent une grande partie des pilotes matériels, et le micrologiciel du chargeur de démarrage qui est chargé avant le noyau dans la chaîne de démarrage, sont complètement à source fermée dans la plupart des cas (propriété intellectuelle de l'équipementier/vendeur de logiciels). Ainsi, le logiciel des appareils Android que nous connaissons est au moins l'AOSP + le noyau + les HALs + les chargeurs de démarrage (et d'autres micrologiciels SoC).
Les OEM obtiennent gratuitement de Google une copie de la version AOSP (en théorie ; en réalité, ils sont liés par des contrats), ajoutent leur code propriétaire qui peut aussi remplacer inutilement le code AOSP (par exemple pour changer les visuels) et ajoutent de nouvelles applications/fonctionnalités, construisent la ROM et la publient avec l'appareil (ou comme paquet de mise à jour OTA plus tard). Les clés - qui sont utilisées pour signer les applications système/framework et mettre à jour les paquets. après - sont construites/définies pendant Processus de compilation des ROM qui est effectué par l'OEM, donc l'OEM possède les clés privées. Cela permet de s'assurer que les composants centraux du système d'exploitation ne reçoivent pas de futures mises à jour provenant de sources non fiables. La plupart des équipementiers ajoutent également les services Play et d'autres applications (GMS) exclusives de Google, déjà signées avec les clés privées de Google, de sorte que les mises à jour proviennent directement de Google.
Android ONE :
Le programme Android One était légèrement différent au début. Une citation de Pour les cinq prochains milliards : Android One :
"Pour garantir une expérience cohérente, les appareils Android One recevront les dernières versions d'Android directement de Google."
Mais leur vision d'un Android pur sur des appareils avec des exigences matérielles strictes n'a pas séduit les équipementiers. tweak stratégie Android One et le plan est passé à :
"Les téléphones Android One reçoivent la dernière version d'Android des partenaires matériels de Google. Les partenaires de Google envoient les mises à jour en fonction de leur calendrier - en essayant de vous les faire parvenir le plus rapidement possible."
* Cité par le site de Google mettre à jour la page de support maintenant supprimé.
Pour faire court, les mises à jour OTA - qu'elles soient liées au matériel ou au framework Android - proviennent des OEM. Ils les construisent et les signent avec leurs clés. Google signe soit les mises à jour OTA uniquement pour ses propres appareils (par exemple, Pixel), soit les applications propriétaires (par exemple, Play Store), comme tout développeur d'applications.
Aussi pour Mises à jour A/B :
"Pour les appareils utilisant l'infrastructure OTA de Google, les modifications du système sont toutes dans AOSP, et le code client est fourni par les services Google Play. Les OEM qui n'utilisent pas l'infrastructure L'infrastructure OTA de Google pourront réutiliser le code système de l'AOSP mais devront fournir leur propre client."
Les API de mise à jour du système de l'AOSP ( update_engine ) par défaut utiliser L'autorité de certification racine de Google ( /system/etc/security/cacerts_google ) pour établir https connexion avec le serveur de mise à jour (Omaha ?). Mais les OEM sont libres de modifier le code. Dans chaque cas, l'application client OTA, le démon système et le serveur de mise à jour sont gérés par l'équipementier.
BOOT VERIFIÉ :
Sur les appareils de production release key est utilisé pour signer la mise à jour .zip et peut-être aussi quelques applications. Sa paire de clés publiques est enregistrée sur l'appareil dans /system/etc/security/otacerts.zip , utilisé pour vérifier la signature cryptographique du paquet de mise à jour. Mais il existe en outre un autre mécanisme de signature disponible sur de nombreux appareils depuis Android 5, à savoir Botte vérifiée ( dm-verity ). Les OEM utilisent une paire de clés RSA dans le cadre du mécanisme (A)VB. La clé privée est utilisée pour signer de manière cryptographique l'arbre de hachage de l'ensemble des données de l /system tandis que la clé publique ( /verity_key ) est stocké dans le ramdisk (à l'intérieur de boot.img sur les dispositifs non-SAR) ou le kernel porte-clés du système qui vérifie l'intégrité de dm-verity table de mappage (metablock) ajoutée après le dernier bloc du système de fichiers à la fin de la période d'enregistrement. /system partition. dm-verity table (arbre de hachage) vérifie à son tour l'ensemble de la /system partition en faisant correspondre les hachages. Cela permet de protéger /system contre toute modification involontaire par un logiciel malveillant ou un utilisateur, par exemple en montant des R/W.
Pendant mise à jour OTA par bloc un patch binaire est appliqué à l'ensemble system fichier de périphérique de bloc de partition. Ce correctif est généré en prenant une différence binaire entre l'ancien et le nouveau system.img . Le tableau mis à jour doit être signé par la même clé privée que celle détenue par le développeur de la ROM d'origine, autrement dm-verity échouerait. De la même manière dm-verity protège /vendor y /odm les partitions. boot y recovery sont signées par une autre clé, soit fourni manuellement o construit avec un chargeur de démarrage d'application ou sauvegardé dans un autre endroit sécurisé. Donc c'est seulement l'OEM qui assure cette chaîne de confiance pendant le processus de démarrage, crée toutes les clés dans un premier temps, puis signe et envoie des mises à jour OTA.
