![Android Android](images/news/categories/android.png)
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 .
![](images/base_document.png)
![](images/news_comments.png)
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.