Partout en Europe, une décision semblable est prise dans les capitales. Les gouvernements ont raison de conclure que les affaires sensibles ne doivent pas dépendre des applications de messagerie grand public et que les communications officielles doivent rester sous contrôle national. La France utilise Tchap. L'Allemagne utilise BundesMessenger. La Belgique, la Pologne, le Luxembourg et d'autres pays ont lancé des équivalents nationaux, et l'OTAN en a développé un pour son personnel. La tendance est claire. La question la plus épineuse est de savoir si la souveraineté s'exerce au mieux par la maîtrise du code source ou par la maîtrise des mécanismes de contrôle qui déterminent où le système est exécuté, qui en détient les clés, quelle loi le régit et qui est responsable de sa sécurité.

BlackBerry Secure Communications aborde cette question en s'appuyant sur une longue expérience des communications sécurisées de niveau gouvernemental, notamment dans des déploiements où le contrôle national, l'exploitation sur le territoire national et la certification sont des impératifs. La souveraineté doit être la norme. La question est de savoir si une plateforme développée à l'interne ou une technologie certifiée déployée selon les modalités nationales offre un contrôle renforcé à long terme, et quelles mesures un pays doit prendre pour garantir la sécurité de ce contrôle.

Construire ou déployer selon les conditions nationales

Les gouvernements disposent généralement de deux façons d'exercer un contrôle souverain sur les communications officielles :

1. Ils peuvent créer ou dupliquer leur propre plateforme et l'exploiter eux-mêmes ;

2. Ils peuvent déployer des logiciels commerciaux certifiés entièrement selon leurs propres conditions : sur une infrastructure nationale, avec des clés de chiffrement détenues par l'État et par personne d'autre, approuvées par leur propre autorité nationale et exploitées à l'intérieur de leurs frontières.

Les deux approches permettent à un gouvernement de garder le contrôle. La différence ne réside pas dans l'objectif, mais dans le modèle opérationnel adopté par un pays pour l'atteindre. Une plateforme développée à l'interne concentre la responsabilité des correctifs, de la certification, du personnel, de la résilience et du financement à long terme au sein d'un seul programme national. Un modèle d'affaires certifié peut préserver le contrôle national tout en s'appuyant sur une expertise technique pointue, une capacité de réponse aux vulnérabilités et une expérience opérationnelle déjà éprouvée auprès d'une clientèle plus large.

Le processus de développement séduit pour des raisons compréhensibles : il incarne l’indépendance la plus totale ; les outils modernes permettent de mettre en place un prototype fonctionnel plus rapidement que jamais ; et une plateforme nationale peut être présentée comme un investissement dans les capacités nationales. Aucune de ces motivations n'est erronée. Mais elles décrivent le moment du lancement. Le véritable défi consiste à déterminer ce que le pays devra financer, doter en personnel, certifier et défendre une fois la plateforme opérationnelle.

Ce à quoi un projet de construction implique un pays

Presque aucun des systèmes de messagerie nationaux actuellement en service n'a été développé ex nihilo. La plupart sont des versions dérivées d'une même plateforme open source, adaptées puis entretenues par l'État. C'est un choix technique judicieux. Cela signifie également que le gouvernement hérite de tout ce qui dépend de cette plateforme, et ce, de manière permanente.

La mise en place d'une plateforme est un projet qui a un début et une fin. Assurer sa sécurité est une responsabilité permanente des pouvoirs publics. Cela implique des correctifs continus, un fonctionnement 24 heures sur 24, 7 jours sur 7, une certification régulière, une expertise interne en cryptographie et sécurité, ainsi qu'une obligation de rendre des comptes publiquement en cas d'incident.

Le coût d'une mise en place est souvent présenté comme un investissement unique. En réalité, il s'agit du coût total de possession sur dix ans, dont la majeure partie survient après le lancement. Les correctifs continus, un centre d'opérations de sécurité, les certifications récurrentes et les spécialistes qui les gèrent coûtent sensiblement le même prix, qu'ils servent un seul gouvernement ou cinquante. Un fournisseur assure le maintien de ces capacités une seule fois et les répartit entre tous ses clients. Un gouvernement qui développe sa propre solution en assume la totalité du coût avec son budget national unique. 

La charge opérationnelle est identique sur les deux itinéraires. La différence est qu'un seul budget national peut la supporter.

La menace a changé la donne.

Il y a une nouvelle dimension que toute personne évaluant la stratégie de déploiement devrait prendre en compte aujourd'hui. À mesure que les outils automatisés réduisent le délai entre la divulgation d'une vulnérabilité et son exploitation, la contrainte déterminante n'est plus la capacité financière d'un gouvernement à appliquer un correctif, mais sa capacité à le faire avant que la faille ne soit exploitée.

Plus tôt cette année, l'une de ces plateformes nationales a subi une intrusion. Aucun chiffrement n'a été compromis et aucune faille du logiciel n'a été exploitée. Un seul compte utilisateur a été piraté, ce qui a suffi pour accéder aux espaces publics non chiffrés, accessibles à tout utilisateur authentifié grâce à l'architecture du système. Le chiffrement a parfaitement rempli sa fonction. La vulnérabilité semble provenir de l'architecture sous-jacente : un modèle hérité d'une fondation open source et maintenu au sein d'un programme national unique.

La profondeur est essentielle car la réponse aux vulnérabilités dépend de la télémétrie, du renseignement sur les menaces, des capacités d'ingénierie, de la visibilité client et de la rapidité des tests et du déploiement. Une petite équipe nationale qui attend un correctif en amont qu'elle ne contrôle pas est structurellement désavantagée dans une course maintenant qui se joue en heures. Une organisation qui gère la réponse aux vulnérabilités pour une large clientèle est mieux placée pour réagir plus rapidement à mesure que la menace s'accélère.

La résilience suit la même logique. La capacité de résister aux pics de charge, aux réseaux dégradés et aux infrastructures potentiellement attaquées est éprouvée dans de nombreux déploiements, et n'a pas été démontrée pour la première fois lors du premier incident national affectant une plateforme.

Lorsque l'exploitation survient quelques heures après la divulgation, la responsabilité de la correction importe plus que la paternité du code.

Plus qu'une simple application de messagerie

Il y a un autre aspect que les fourchettes de courriels ne prennent pas en compte. Sécuriser la voix et la messagerie représente un véritable défi, et un fork qui l'intègre constitue un progrès considérable. Cependant, la sécurité des communications ne se limite pas à la messagerie. L'appareil sur lequel la conversation s'exécute doit également être protégé, sinon la sécurité de l'échange dépend de celle du terminal sous-jacent. Lorsqu'un incident touche plusieurs agences sans hiérarchie commune, la réponse doit être coordonnée entre elles. Chaque couche est indépendante, avec ses propres exigences de certification et de gestion. Une fourche fournit la première couche. Un gouvernement qui souhaite disposer de toutes les capacités s'engage, de fait, à bâtir et à maintenir plusieurs plateformes.

La souveraineté, c'est le contrôle, pas la création.

Derrière tout ça se cache une confusion qu'il faut nommer. La souveraineté est parfois réduite à la question de savoir qui a écrit le code, alors qu'il s'agit en réalité d'une question de contrôle : qui détient les clés, où le système est exécuté, quelle loi le régit et qui en est responsable ? Un gouvernement peut écrire chaque ligne de code et pourtant dépendre d'un fournisseur étranger pour les correctifs de sécurité. Il peut également déployer des logiciels commerciaux tout en conservant le contrôle de tous les points d'accès essentiels, si l'architecture est conçue à cet effet.

C'est cette distinction que tout gouvernement confronté à ce choix devrait retenir. L’objectif n’est pas la paternité du logiciel pour le simple plaisir de l’utiliser. L'objectif est de contrôler où il s'exécute, qui en détient les clés, qui le certifie et l'exploite, et qui est responsable de sa défense. La paternité du logiciel peut être une voie d’accès à ce contrôle, mais ce n’est qu’une avenue parmi d’autres. Les ressources techniques, l’attention opérationnelle et le budget annuel requis par une plateforme développée à l’interne sont limités. Les sommes investies dans ce domaine ne peuvent pas être consacrées au reste des missions de sécurité nationale. Parmi les nations partageant les mêmes valeurs, la résilience est renforcée par la coopération lorsque cela est pertinent, plutôt que par la reconstruction isolée d’une infrastructure identique.

Secusmart illustre ce modèle en pratique. Cette entreprise allemande, conçue et exploitée au sein des structures allemandes et certifiée par l'autorité fédérale compétente, est présente depuis des années dans le paysage national des communications gouvernementales sécurisées. Elle démontre que la souveraineté ne signifie pas nécessairement une reconstruction complète et isolée. Les gouvernements devraient exiger une souveraineté sans compromis, puis évaluer le coût total sur dix ans avant de choisir le modèle à adopter.