Le Raspberry PI et la chaudière... WTF ? (épisode 1)

Sécurité des applications
Le Raspberry PI et la chaudière... WTF ? (épisode 1)

Suite à la révision de ma chaudière, l’idée m’est venue de la piloter par un système automatisé. J’ai immédiatement pensé à mon fidèle RPi qui, petit à petit, est en train de rendre ma maison « intelligente », comme on dit maintenant.

Passé le choix de la technologie (Z-wave), du capteur de température et du micromodule de commande, le système est opérationnel.

Reste maintenant à créer la petite interface de contrôle qui va bien et mon système « SCADA personnel » me donnera entière satisfaction.

Si l’on veut que cette interface soit « sexy » et accessible à distance (pratique pour ajuster la température de la maison avant le retour de vacances), il faut ouvrir le système sur l’extérieur...

Pas très compliqué d’ouvrir un port sur Internet et d’en assurer la sécurité via les protections périphériques et les systèmes d’authentification forte que tout le monde connait... Bref, il ne reste plus qu’à coder une petite interface d’administration sympa, utilisable facilement depuis un PC, une tablette ou un Smartphone.

Les connaisseurs diront probablement que je perds mon temps, car il suffirait d’ouvrir mon installation sur Internet et de la piloter depuis un Cloud prévu à cet effet (Voir http://fr.z-wave.me/) – mais j’ai quelques réticences sur le sujet, ne sachant pas où sont mes données et n’ayant aucune garantie sur le niveau de sécurité.

 

Trois approches s'offrent donc à moi

Native vs Hybrid vs HTML5

1. Développer une application native

  • Elle enverra ses consignes au RPi et recevra ses acquittements

2. Développer une "WebApp" sur le RPi

  • L'application pilote directement le contrôleur Z-Wave
  • Elle serait accessible depuis n'importe quel périphérique

3. Développer une application hybride

  • Application native qui "enrobe" du contenu HTML5
  • Framework "WEB" (html, css, js) avec un "SDK natif" (ex : http://phonegap.com/)

Les solutions pour générer du code Cross Compilé (ala Titanium / Appcelerator ou Adobe AIR), permettent de ne développer qu’une seule application et de l’exécuter sur plusieurs environnements. Je les classe dans la catégorie des applications natives.

Petit rappel sur application native et HTML5 (tiré de Journal du Net) :

Une application HTML5 est hébergée sur Internet et s'opère dans un navigateur mobile.

A la différence des [applications natives], applications créées spécifiquement pour les appareils Apple ou pour l'OS Android, elle n'a pas besoin d'être développée à partir de 0 pour chaque OS.

Sa devise : "Write once, run anywhere."

Je suis immunisé contre les conséquences d’un vol du Smartphone / de la tablette grâce au système d’authentification forte en place, mais je ne suis pas à l’abri d’une faille sur l’équipement – faille qui permettrait à une organisation terroriste de prendre le contrôle à distance de ma chaudière (on ne se méfie jamais assez de ses voisins…).

Mes critères de choix sont les suivants :

  • Facilité du développement de l’application : Le coût (ie : le temps pour moi) vs flexibilité
  • La « sexitude » : La tablette Android fixée sur le mur du salon doit donner envie de s’en servir
  • La sécurité, évidemment !

Comme tout amateur éclairé qui se respecte, je démarre une recherche Google… et là je découvre qu’un million de personnes se sont posées la question avant moi.

 Me voilà donc parti à éplucher les forums et à décortiquer les arguments et les discours des « pros » et des « cons » (vous pouvez le lire en Français ou en Anglais). J’ai synthétisé les arguments glanés sur Internet en essayant d’apporter un regard « sécurité ».

Je ne cite pas (de peur des représailles) les sources des éléments collectés, mais vous pouvez utiliser les résultats de la recherche « HTML5 vs native » dans Google pour vous en faire une idée :) .

Commençons par dire du bien des articles (le point « sécurité » mis à part) qui concluent que le choix doit principalement se faire en fonction de la nature de l’application et du budget dont on dispose (cf. plus bas). Jusque là on est en phase…

Poursuivons en affirmant que peu d’articles comprennent le mot « sécurité » et, lorsqu’ils en parlent, c’est pour balancer des affirmations gratuites sans le moindre début d’argumentation :

  • Les applications natives sont, évidemment, bien plus sécurisées que les applications Web
  • Les applications Web sont, évidemment, impossibles à sécuriser
  • Les applications hybrides réunissent le meilleur des deux mondes

En synthèse, tout le monde semble en phase avec ICAPS.COM qui résume la situation ainsi :

Bon… mon étude est donc terminée, je vais développer une application avec le SDK Android. C’est du natif, donc « supra-sexy », « méga-performant » et « Über sécurisé ».

La faille « Master Key » qui affecte 99% (un peu moins maintenant) des Android c’est du Bullshit. L’IOS n’a jamais connu de faille de sécurité, Windows 8 n’en parlons pas et le Jailbreak c’est une légende urbaine…

Rien à signaler du côté de la sécurité des applications mobiles, circulez !

Comment m’y prendre ? La suite au prochain épisode.

Pour lire l'épisode 2, cliquez ici.

Jérémie Jourdin, Responsable R&D, Advens