Google a toujours dirigé le développement d'Android, le système d'exploitation bien connu qui anime la plupart des smartphones dans le monde. Après la sortie publique d' Android 13 , nous voyons Android 14 à l'horizon . Android 14 n'arrivera pas avant le milieu de l'année prochaine en version bêta, pour une sortie de l'écurie attendue entre la fin de l'été et le début de l'automne prochain. Au cours des dernières heures, Esper a trouvé des nouvelles intéressantes qui pourraient arriver en termes de sécurité avec Android 14. Ces nouvelles fonctionnalités consistent en la mise en place de certificats racine pouvant être mis à jour . Ceci est particulièrement important et pour comprendre pourquoi il est nécessaire de comprendre de quoi on parle. En termes simples, les certificats racine sont des certificats de sécurité fournis par des sites Web, des applications et du contenu Web qui interagissent avec les smartphones Android . Ces certificats permettent à l'appareil Android d' accéder en toute sécurité au contenu auquel ils se réfèrent. Par exemple, un site Web sera marqué comme non sécurisé s'il ne fournit pas le certificat de sécurité requis. Ce mécanisme de fourniture de certificats s'effectue par l'intermédiaire de tiers qui certifient le cryptage correct du contenu et du cryptage utilisé pour les données échangées avec l'appareil Android. Chaque appareil Android s'attend à ce que ces certificats soient stockés dans un registre de la mémoire interne. Ce registre peut également être consulté par l'utilisateur final, et vise à accélérer l'accès aux contenus, applications ou sites Web précédemment visités.
L'introduction de certificats racine pouvant être mis à jour rendrait la question de la modification d'un certificat beaucoup plus facile à gérer. Actuellement, si un certificat est modifié , cela signifie qu'un nouveau doit être acquis pour un accès correct au contenu auquel il se réfère. En d'autres termes, Android traite actuellement un certificat modifié comme un nouveau certificat , c'est-à -dire non modifiable. Cela implique des problèmes en termes de délais , car la suppression de l'ancien certificat et l'acquisition de sa nouvelle version peuvent prendre un certain temps et entraîner des dysfonctionnements en raison de l'impossibilité d'accéder au service lié au certificat. La mise à jour des certificats racine nécessite actuellement une mise à jour logicielle via OTA , ce n'est pas un processus très rapide. Avec la prise en charge des certificats racine pouvant être mis à jour, il serait plutôt possible de publier plus rapidement des mises à jour via le système de jeu .
L'introduction de certificats racine pouvant être mis à jour rendrait la question de la modification d'un certificat beaucoup plus facile à gérer. Actuellement, si un certificat est modifié , cela signifie qu'un nouveau doit être acquis pour un accès correct au contenu auquel il se réfère. En d'autres termes, Android traite actuellement un certificat modifié comme un nouveau certificat , c'est-à -dire non modifiable. Cela implique des problèmes en termes de délais , car la suppression de l'ancien certificat et l'acquisition de sa nouvelle version peuvent prendre un certain temps et entraîner des dysfonctionnements en raison de l'impossibilité d'accéder au service lié au certificat. La mise à jour des certificats racine nécessite actuellement une mise à jour logicielle via OTA , ce n'est pas un processus très rapide. Avec la prise en charge des certificats racine pouvant être mis à jour, il serait plutôt possible de publier plus rapidement des mises à jour via le système de jeu .
Plus d'actualités dans cette catégorie
Commentaires
Zyphos:
Android 14 et certificats racine pouvant être mis à jour : pourquoi c'est imp...
Je réagis un peu tard, mais il y a eu une mauvaise compréhension du journaliste sur les certificats racines.
Les certificats racines ne sont PAS lié directement au certificat utilisé par les site Web ou autre services SSL.
Les certificats racines servent à établir la confiance de la chaîne de certification. On décide de les accepter tels quels et ils changent très rarement. (Validité 25 ans par exemple).
Les certificats server surtout à signer des clés publiques. (On génère la clé privé et la clé public en privé, puis on demande à une organisation de certification de la signer, ils nous donnent après vérification de notre identité, le certificat signé)
Pour les sites web, ceux-ci sont inclus dans les browsers (navigateurs).
Exemple de la chaîne de certification pour Wikipédia:
1. Le certificat du nom de domaine générique "*.wikipedia.org" émit par DigiCert Inc (donc DigiCert a vérifié que le nom de domaine wikipedia.org leur appartenait bien) validité courte (ici 1 an +20 jours, lets encrypt c'est 3 mois, en général c'est 1 an)
ce certificat est certifié par:
2. Le certificat de certification "DigiCert TLS Hybrid ECC SHA384 2020 CA1" (validité 10 ans), sa clé privé donc déjà être sûrement dans un "coffre fort".
ce certificat est certifié par:
3. Le certificat racine de DigiCert à savoir "DigiCert Global Root CA" (validité 25 ans), sa clé privé doit être dans un "super coffre fort". Ce certificat est joint avec l'installation du navigateur. (ex: Firefox)
Certains navigateurs ont par exemple refusé la confiance de certain certificat racine, par exemple en 2016, beaucoup de société ont retiré leur confiance dans la société Starcom, (elle venait d'être racheté par WoSign, une société Chinoise qui a émit de faux certificats rétro actif.
https://en.wikipedia.org/wiki/StartCom
Ici pour Android on parle de certificat racine permettant de vérifier, entre-autre, la signature des applications ou mise à jour par exemple.
Le fait de pouvoir modifier ces certificats racines, permet surtout de réagir vite si une des clés privées certifiées par les certificats racines est compromise. (Volée ou rendue publique)
Par ce que si on obtient une clé privée dont la clé publique est certifiée par un certificat racine, on peut créer d'autres certificats comme on veut, et signer n'importe quelle application, ou mise à jour.
Bref, on ne peut plus garantir l'origine d'une mise à jours, ou application. Bref on peut installer une backdoor ou ransomware, ou tout autre application de manière tout à fait officielle.
Les certificats racines ne sont PAS lié directement au certificat utilisé par les site Web ou autre services SSL.
Les certificats racines servent à établir la confiance de la chaîne de certification. On décide de les accepter tels quels et ils changent très rarement. (Validité 25 ans par exemple).
Les certificats server surtout à signer des clés publiques. (On génère la clé privé et la clé public en privé, puis on demande à une organisation de certification de la signer, ils nous donnent après vérification de notre identité, le certificat signé)
Pour les sites web, ceux-ci sont inclus dans les browsers (navigateurs).
Exemple de la chaîne de certification pour Wikipédia:
1. Le certificat du nom de domaine générique "*.wikipedia.org" émit par DigiCert Inc (donc DigiCert a vérifié que le nom de domaine wikipedia.org leur appartenait bien) validité courte (ici 1 an +20 jours, lets encrypt c'est 3 mois, en général c'est 1 an)
ce certificat est certifié par:
2. Le certificat de certification "DigiCert TLS Hybrid ECC SHA384 2020 CA1" (validité 10 ans), sa clé privé donc déjà être sûrement dans un "coffre fort".
ce certificat est certifié par:
3. Le certificat racine de DigiCert à savoir "DigiCert Global Root CA" (validité 25 ans), sa clé privé doit être dans un "super coffre fort". Ce certificat est joint avec l'installation du navigateur. (ex: Firefox)
Certains navigateurs ont par exemple refusé la confiance de certain certificat racine, par exemple en 2016, beaucoup de société ont retiré leur confiance dans la société Starcom, (elle venait d'être racheté par WoSign, une société Chinoise qui a émit de faux certificats rétro actif.
https://en.wikipedia.org/wiki/StartCom
Ici pour Android on parle de certificat racine permettant de vérifier, entre-autre, la signature des applications ou mise à jour par exemple.
Le fait de pouvoir modifier ces certificats racines, permet surtout de réagir vite si une des clés privées certifiées par les certificats racines est compromise. (Volée ou rendue publique)
Par ce que si on obtient une clé privée dont la clé publique est certifiée par un certificat racine, on peut créer d'autres certificats comme on veut, et signer n'importe quelle application, ou mise à jour.
Bref, on ne peut plus garantir l'origine d'une mise à jours, ou application. Bref on peut installer une backdoor ou ransomware, ou tout autre application de manière tout à fait officielle.