Des gens utilisent le Blackberry qui est, et c'est incontestable, un excellent outil, sinon le meilleur du marché, de type smartphone. Chacun a effectivement sa sensibilité, mais objectivement, le Blackberry, ça déchire : zéro config ou presque, ça marche, les messages, attachements compris, sont traités, découpés et reformatés pour être lus sur le mobile, etc. Et c'est ce qui fait sa force quasi-addictive. Ceux qui y ont goûté peuvent difficilement s'en passer, à tel point qu'on dit de ses utilisateurs compulsifs qu'ils sont "Blackburied". Et c'est manifestement ce qui se produit dans nos chers ministères. Situation nouvelle ? Non, absolument pas. Depuis l'introduction du produit en France, de nombreuses sociétés se sont retrouvées face au même problème, qu'elles ont résolu de manières différentes, souvent radicales. Pourquoi ? Je vais y revenir. Toujours est-il que ce mobile dont les communications sont relayées par d'étranges serveurs génère du buzz quant à sa sécurité.

Au-delà de ceux, rares, qui se sont posés la question de manière objective, on trouve malheureusement surtout une grosse masse de spéculateurs et de diseuses de bonne aventure si je puis m'exprimer ainsi, qui se situent dans un camp comme dans l'autre. Mon confrère, mais néanmoins ami, jme fait une analogie remarquable dans son dernier billet consacré à ce sujet : "Le SGDN c'est comme ma grand-mère". D'un côté vous avez les gens qui en ont peur. Parce qu'ils ne comprennent pas. Et de l'autre, vous avez les gens qui n'en ont pas peur. Parce qu'ils comprennent, eux ? Pas sûr...

Mais, revenons à nos moutons. Le Blackberry est-il espionnable ? Le problème de cette question, au-delà de ce qu'on entend par espionnable, est qu'elle en appelle en fait deux, à deux niveaux de réflexion différents. La première relève de la technique pure : est-il techniquement possible de récupérer les emails en clair ? Et désolé de vous pourrir la suite, mais techniquement, c'est possible. La seconde question est plus prospective : quand bien même l'écoute serait possible, est-elle mise en œuvre ? Et c'est cette seconde question qui est épineuse d'abord parce qu'elle soupsonne la présence d'une backdoor dans le code, ce qui est loin d'être anodin pour l'éditeur, Research In Motion[1], et ensuite parce qu'elle ne peut pas forcément être résolue par la seule technique...

Je vous le disais précédemment, sur un plan purement technique, oui, l'espionnage du Blackberry est possible. Comme celui de n'importe quel autre appareil de ce type. Et ce à deux niveau qui sont allègrement mélangés par nos journalistes préférés.

Le premier, c'est celui de la sécurité du système dans son design et son implémentation. L'argument que les afficionados du BB avancent pour justifier de sa sécurité est que les messages sont protégés par un chiffrement de bout en bout entre le BES[2] et le mobile. Et que ce chiffrement est fait en AES, que cet algorithme tient la route, d'autant que les clés font 256 bits. Il semble que ce soit effectivement le cas, et dès lors, le problème du cassage du lien de communication peut être écarté. Mais cette affirmation est-elle suffisante pour déduire que le système Blackberry est sûr ? Parce qu'elle se concentre uniquement sur l'algorithme de chiffrement, mais pas son implémentation, cette réponse me paraît un peu courte. Ron Rivest[3] écrivait : "with these sort of schemes the devil is always in the details, and there are lots of details". Cette phrase que les francophones pourront traduire par "avec ce genre de mécanismes, le diable se cache toujours dans les détails, et il y a beaucoup de détails" s'applique très bien à la situation. On sait, ne serait-ce que par expérience, qu'il y a de nombreuses façon de se prendre les pieds dans le tapis quand on implémente de la crypto.

Autre question : la crypto est-elle la seule source de problèmes ? Non, évidemment. Se focaliser sur la seule sécurisation du canal de communication reviendrait en effet à oublier qu'on peut accéder aux messages ailleurs que dans les flux communications : sur le BES, sur le mobile et sur le serveur de messagerie. D'où des questions qui viennent naturellement. Est-il possible de compromettre un BES ? Ou un mobile ? Cette première éventualité a été démontrée par des gens de mon labo puis par FX. On remarquera d'ailleurs que ce que RIM qualifie aujourd'hui dans la presse de faille mineure rapidement patchée, pouvait à l'époque conduire à une exécution de code distante[4] sur un logiciel qui s'installait alors avec les privilèges administrateur et un accès complet au serveur de messagerie... Rassurez-vous, c'est vieux de deux ans et c'est patché, tout comme les failles mises en exergue par FX. Quant à la corruption du mobile, elle n'a pas été démontrée. Il est cependant relativement naturel de penser qu'une faille présente dans une routine de décompression sur le BES puissent se retrouver également sur le device. À la dernière Defcon, Jesse d'Aguanno abordait le problème autrement en faisant la démonstration d'un trojan permettant de relayer silencieusement des communications via un Blackberry et son BES pour atteindre le cœur de l'entreprise depuis Internet. Sans même considérer la présence éventuelle de pare-feu entre le BES et le reste du réseau, rares sont ceux qui ont réussi à reproduire ce comportement, en particulier si on considère la politique de sécurité par défaut. C'est d'ailleurs ce que tend à montrer[5] la récente étude de Symantec sur le device proprement dit et qui mérite une lecture attentive[6].

Je ne veux pas dire par là que la solution n'est pas sécurisée. Non, loin de là. Juste que le système Blackberry n'est pas une exception à la règle : comme toute solution, il souffre parfois de manques et de problèmes de sécurité. Et l'application de la méthode Coué consistant à reprendre en boucle l'argumentation de la plaquette commerciale, comme quoi il s'agirait de la solution la plus sécurisée du marché, ne changera rien à cela, quand bien même ce serait vrai. Comme disait quelqu'un que je salue au passage, c'est un peu comme essayer de redresser la banane. Une banane, c'est courbe, c'est comme ça, et on ne peut pas y changer grand chose[7]...

Il convient donc de considérer le risque et se donner les moyens de le limiter, ce qui ne veut pas pour autant dire interdiction de la solution. Un déploiement exploitant les possibilités de ségrégation et de limitation de privilèges disponibles dans les versions actuelles permet par exemple d'augmenter sensiblement le niveau de sécurité de l'ensemble. L'utilisation des politiques de sécurité est également quelque chose à considérer sérieusement.


La seconde est l'hypothèse, qui a la vie dure dans cette histoire, de l'existence d'une backdoor permettant à une puissance étrangère d'espionner nos communications sensibles. Une fois entré sur ce terrain, tous les délires sont permis tant il y a de façon de mettre ça en place. Une faille par exemple peut très bien n'être en fait qu'une backdoor déguisée permettant d'accéder au système, tout comme une erreur d'implémentation cryptographique. Et même en ne s'attachant qu'au canal de communication, pas besoin de casser AES : la fuite de clé est un excellent candidat. Mais pourquoi se poser la question pour le Blackberry en particulier, dans la mesure où tous les systèmes propriétaires peuvent faire l'objet de ce genre de manipulation ? D'abord parce que le Blackberry est assimilé à un téléphone, équipement avec lequel son propriétaire a une relation particulière, presque affective. Et surtout, il y a le contexte. Dans le système Blackberry, il y a un mobile, un protocole de communication propriétaire et des serveurs relais. Le code qui tourne sur le mobile n'est pas forcément entièrement accessible, voire implanté en hard sur une puce, permettant la mise en place de fonctionnalités extrêmement difficiles à détecter. Ensuite, le protocole propriétaire rend très compliquée la détection de fuites, considérant qu'en plus, il faut pouvoir intercepter le canal GPRS pour l'observer. C'est possible, mais pas pour le quidam lambda. Ça demande des moyens et du boulot. Enfin, il y a ces fameux serveurs relais, dits SRP[8], opérés par RIM aux USA, Canada et Angleterre, et qui font forcément couler des torrents d'encre parce qu'il constituent un point idéal d'interception des données. Si backdoor il y a.

Car si backdoor il y a, tout de suite, l'hypothèse prend du corps : le mobile ferait fuiter la clé de chiffrement dans un canal caché sur le protocole propriétaire, ce qui permettrait au SRP de la récupérer et déchiffrer le message intercepté. CQFD. Et on voit bien que ce n'est pas très difficile. Le mobile est un équipement particulièrement adapté pour cacher du code, le protocole propriétaire chiffré permet de camoufler les fuites et le SRP n'a plus qu'à écouter le trafic qu'il route. Sauf que... Sauf que personne n'a pu mettre en avant la moindre preuve de l'existence de cette backdoor. Parallèlement, absolument rien, à part la supposée bonne foi de RIM, ne nous indique qu'il n'y en a pas. Et c'est bien là que le bât blesse : ne pouvant prouver ni l'existence[9], ni l'absence de backdoor, les spéculations vont bon train.


Alors comme me le demandait Yom récemment, qu'est-ce que je pense de tout ça ? Et bien d'abord qu'il convient de ne pas mélanger faits et spéculation. La solution Blackberry a connu des failles et en connaîtra probablement d'autres. Ceci ne veut pas pour autant dire qu'elle contienne une backdoor. Que je ne sais fichtre pas s'il y a une backdoor ou non dans ce produit. Est-ce que c'est crédible, probable ou tout simplement délirant ? Je n'en sais rien ! Je sais que c'est techniquement possible, mais mon avis de technicien s'arrête là. Personnellement, je ne travaille pas dans le renseignement, je suis grossièrement l'actualité, alors d'ici à savoir si le contexte géo-politique mondial rend cette hypothèse crédible ou non, il y a un pas que je vais me garder de franchir. Clairement. Ensuite que cette polémique est largement alimentée par des gens dont le seul but est de faire du bruit tant il est évident qu'ils ne savent pas de quoi ils parlent. Enfin que, comme je le disais à la table ronde de la JSSI l'an dernier, il faut prendre le problème sereinement et se donner les moyens de se forger sa propre opinion, qui peut tout à fait diamétralement différer entre deux entités, selon leur perception du risque. À chacun de se forger sa propre opinion sur la question, d'estimer son risque et d'agir en conséquence, le tout en fonction des informations qu'il a en main.


Mais pendant ce temps à Vera Cruz et ailleurs dans le monde, pendant que les beaux parleurs s'escriment, le Blackberry est déjà dans les chaumières, qu'on le veuille ou non. Et lorsque le jouet n'est pas compris dans le package professionnel standard, certains n'hésitent pas à souscrire un abonnement à titre personnel vers lequel ils font suivre leur correspondance[10], sans parler des VIP qui l'exigent. Dès lors, si vous voulez adresser le risque lié à l'utilisation de cet engin, vous vous retrouvez plus souvent dans un mode "damage control" que véritablement en position de vous demander s'il faut y aller ou pas. Et là encore, ce ne sont pas les technico-techniciens qui, même s'ils peuvent montrer des pistes intéressantes, vous apporteront des réponses définitives...


Je posais la question de savoir pourquoi beaucoup en sont là aujourd'hui. Il y a là, je pense, un des signes d'un bouleversement du triangle employé, entreprise, informatique. Auparavant, c'était l'entreprise qui poussait les moyens informatiques pointus vers ses employés. Aujourd'hui, on assiste à un renversement complet, avec des entreprises qui se retrouvent en retard par rapport à ce que les individus savent d'une part, et ce à quoi ils ont accès à titre personnel d'autre part. D'où une position défensive vis-à-vis des attentes des utilisateurs, souvent incompatible avec la nécessité de maîtrise technologique. Et ce n'est pas Skype qui échappe à la règle, polémique comprise...

Notes

[1] RIM pour les intimes.

[2] BlackBerry Entreprise Server.

[3] Un des trois auteurs de RSA.

[4] Dans le texte : "This vulnerability could potentially allow for remote code execution".

[5] Je cite: Note that in a default BES deployment, the firewall is enabled, and the user will receive additional prompts before connections are allowed, even for signed code.

[6] Si si, les "Attack Surface of..." sont intéressants, je vous assure...

[7] Sauf si on se lance dans la génétique, et encore...

[8] Server Router Protocol.

[9] Sauf implantation grossière...

[10] Exactement comme avec Gmail ou Yahoo quand ils n'ont pas de webmail corporate !...