Signa­ture des appli­ca­tions Android sur Google Play


Je trouve très peu de conseil ou bonnes pratiques. Déve­lop­peurs Android qui avez de l’ex­pé­rience là dedans, j’ai besoin de vos lumières.

Pour l’ins­tant j’ai lu Signing you appli­ca­tions. J’ai retenu que toutes les appli­ca­tions doivent être signées, et que pour pouvoir les mettre à jour il faut utili­ser exac­te­ment le même certi­fi­cat que l’ap­pli­ca­tion d’ori­gine. Pour signer on créé un keys­tore et un alias.

Une ou plusieurs clefs

La bonne pratique habi­tuelle côté sécu­rité c’est une clef par desti­na­tion, appli­ca­tion ou usage. Éven­tuel­le­ment une clef globale pour certi­fier les premières si on a besoin de s’as­su­rer de la pater­nité de toutes les clefs. Ça mili­te­rait pour signer chaque appli­ca­tion avec une clef diffé­rente et ça permet­trait de délé­guer la produc­tion d’une ou plusieurs appli­ca­tions à un tiers sans devoir lui donner la clef globale.

Le problème c’est que le docu­ment sur la doc Android, ainsi que les quelques docu­ments trou­vés sur le web à propos de Google Play, conseillent plutôt d’uti­li­ser une clef globale. Le seul gain que j’y vois c’est que les appli­ca­tions pour­ront commu­niquer entre elles. Je n’en ai pas besoin pour l’ins­tant mais il est vrai que je ne connais pas le futur.

Alors, une clef par appli­ca­tion ou une clef globale ?

Notion de keys­tore et alias

Tel que je le comprends le keys­tore n’est qu’un simple entre­pôt pour stocker des clefs. Mis à part que lui même peut être protégé par un mot de passe pour éviter de donner trop faci­le­ment accès aux clefs privées. Les clefs privés sont en fait ce qui est pointé par les « alias » dans la docu­men­ta­tion. On peut donc avoir plusieurs clefs par keys­tore.

J’en déduis que la notion de keys­tore n’in­flue pas du tout sur Google Play. Je peux sortir ma clef d’un keys­tore, la mettre dans un autre keys­tore et signer une mise à jour avec. Tant que c’est la même clef, on se moque du keys­tore. Ai-je bon ?

J’en déduis donc aussi que Google n’a aucune notion de mon keys­tore et que je peux y ajou­ter de nouvelles clefs quand je le souhaite pour de nouvelles appli­ca­tions. Je n’ai pas besoin de prépa­rer un keys­tore avec un jeu de clef qui ne bougera pas et que je ne pour­rai pas mettre à jour. Ai-je bon ?

Voilà voilà, j’ai besoin de vos lumières et ayant peu d’édi­teurs d’ap­pli­ca­tions dans mon réseau, j’ap­pré­cie­rai beau­coup que vous fassiez suivre mes inter­ro­ga­tions à vos propres connais­sances.

Comme j’ai eu quelques conseils de gens qui réflé­chissent à haute voix mais n’ont eux-même pas essayé ou pas d’ex­pé­rience dans tout ça : Si vous vous retrou­vez dans cette situa­tion, merci de le préci­ser pour que je fasse le tri entre les retours d’ex­pé­rience réels et les autres.


2 réponses à “Signa­ture des appli­ca­tions Android sur Google Play”

  1. C’est ça, le keystore n’est, comme son nom l’indique, qu’un endroit pour stocker les clés. Il n’apporte notamment aucune notion de sous-clé comme dans PGP.

    Ton application devra être signée par la même clé privée lors d’une mise à jour, sinon elle sera refusée par Google Play, et surtout refusée sur le mobile (il faut passer par une phase de désinstallation/réinstallation, bien connue par les développeurs dans les projets collaboratifs où tous les développeurs n’ont pas accès à la clé privée utilisée sur Google Play).

    Signer toutes ses applications avec la même clé est une solution de facilité pour le développeur. Maintenant, en cas de compromission de la clé, ce sont autant d’applications qu’il faudra republier sous une autre identité, car on ne pourra plus avoir confiance en cette clé. D’un autre côté, en pratique, des clés multiples seront souvent stockées dans le même keystore et protégées par le même mot de passe : une compromission touchera donc facilement l’ensemble de ces clés.

    Notons également qu’il est possible de faire communiquer des applications signées avec des clés différentes de manière privilégiée, en utilisant des permissions dédiées.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.