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

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

Suite et fin de mes pérégrinations entre application native et HTML pour piloter ma chaudière. Après avoir épluché les forums et d’abord choisi le SDK Android (c’est du natif) (voir l’épisode 1) puis regardé d’un peu plus près les aspects « sexitude », performance, coûts, contrôle du parc applicatif, mise à jour du logiciel (voir l’épisode 2) il est temps de faire un choix...

Le volet « monétisation » :

Rien à voir avec la sécurité ? Un peu quand même : Qui dit « monétisation » dit « je dois trouver un moyen de protéger mon application ou la donnée gérée par mon application – sinon je ne peux pas la monétiser ».

Les « études » mettent en avant que seuls les modèles « Store » permettent de monétiser les applications. Pas si sûr : Rien n’empêche de bloquer l’utilisation d’une application Web tant qu’un utilisateur ne s’est pas enregistré préalablement. La monétisation de cette phase d’enregistrement ne pose aucun souci. On compte d’ailleurs beaucoup d’applications qui ne permettent pas de jouer en ligne tant que votre compte n’est pas approvisionné, que vous utilisiez l’application native ou la webapp (http://www.fdj.fr par exemple).

Le système de monétisation « en direct » me semble d’ailleurs économiquement plus intéressant puisqu'on se passe des Stores intermédiaires – certes l’exposition est moindre – mais faire sa pub dans le monde du 2.0 n’est pas ce qu’il y a de plus compliqué et le bouche à oreille sur un produit révolutionnaire fera le tour de la planète en moins d’une heure.

Je pense également que les modèles économiques ont radicalement changé : de mon point de vue il ne sert à rien de monétiser l’application – d’ailleurs 100% des applications seront vulnérables un jour ou l’autre et on trouvera toujours une version « Tombée du camion ».

Ce qu’il convient de monétiser en revanche, et c’est plus compliquer à pirater (quand c’est bien fait) ce sont les données exploitées par les applications. Votre application bancaire n’est rien sans vos données, ça marche aussi pour les GPS et ses cartes, les applications de navigation…

L’arrivée de la 4G pourrait accentuer cela puisqu’on pourra accéder en temps réel à des données qui ne sont plus embarquées dans l’application. Idem pour les puces NFC (qui promettent, sur le papier, d’apporter des fonctions de chiffrement matériel) qui pourraient faciliter le développement des solutions à base de DRM.

Par exemple, chez un éditeur bien connu des enseignants, les applications permettant d’acheter les livres scolaires numériques sont en mode hybride : Le contenu binaire reste chez l’éditeur et le logiciel client intègre les fonctions de signature / chiffrement en local. En cas de révocation de la clé du client, le contenu sur le périphérique est illisible – et bien sûr, le contenu est illisible sur un autre périphérique.

Je ne me prononce pas ici en faveur de l’un ou de l’autre, mais en tout cas je n’adhère pas aux arguments avancés sur les forums. Je pense qu’il faut plutôt raisonner « contenu » et ne pas se limiter à l’application en tant que telle. Et pour ma chaudière, je m’en fiche :) .

Le volet sécurité pure

Si vous m’avez suivi jusqu’ici, le meilleur reste à venir… parlons un peu de ce qui se dit sur le Net sur le plan de la sécurité. Je vais résumer les discussions par un florilège d’aberrations trouvées en page principale des « sites d’informations généralistes »

« Pour des besoins forts de sécurité le natif est plus difficile à pirater »

Je serai ravi d’avoir l’étude qui a été menée sur le sujet. Décompiler une application native ça me semble beaucoup plus simple que de faire un test d’intrusion en aveugle sur un site Internet dont on a aucune idée de comment il fonctionne.

L’argument peut être valable mais encore faut-il le développer un peu. Je serai surpris de savoir que toutes les app natives chiffrent nativement les informations qu’elles stockent ou qu’elles envoient. Je n’ai également que peu d’assurance de savoir ce que mon application native fait exactement sur mon mobile… surtout si j’ai désactivé le contrôle sur sa provenance (Même s’il existe des apps pour ça, http://www.pradeo.net/ par exemple).

Enfin le Jailbreak réduit à néant les protections type « Sandboxing ». D’ailleurs, le Sandboxing à la base est fait pour se protéger des autres applications – pas pour se protéger des utilisateurs malveillants qui peuvent chercher à en détourner l’usage - donc cet argument là, je ne l’avale pas, désolé.

« Notification plus efficace de l’utilisateur dans le cas d’une mise à jour »

Aucun commentaire, je l’ai déjà fait plus haut.

 La palme revient au site thinkmobile.appcelerator.com, qui consacre (l’un des seuls !) un pavé sur la sécurité : Security (native wins big) !

“People are increasingly worried about security, especially as mobile moves ever further into the enterprise and, frankly, there is no way that anyone could say that HTML is more secure than a native app. Native clearly wins thanks to:”

“- the security of the source code of itself; browser source code is open for all to see, and to then work around.” 

Personnellement je n’ai jamais eu accès au code source des applications natives, je ne peux donc pas affirmer que ce code est sécurisé. Ce que je sais, c’est que décompiler du code c’est à la portée de presque tout le monde. Je ne rentrerai pas dans le Troll Open Source / sources fermées… Tiens, au fait, Android n’est-il pas un logiciel libre (Open Source) diffusé sous Licence Apache ?

“- the security of data at rest on the device; on a native app, it’s completely secure. In HTML, the browser is typically not secure and as a result exposes the data it’s accessing within its caches.”

Sur le cache du navigateur je suis en phase, en revanche l’auteur n’apporte aucun argument sur les applications natives….

“- the security of data in transit; when using HTML, you are pretty much restricted to using SSL. VPNs are just too slow. With native apps, you can also run VPNs and other encrypted solutions, without ruining performance.”

Ca se passe de commentaires… 

“- URL security vulnerabilities; these are unique to web applications and beloved by hackers. Native apps simply don’t have them, so hackers can’t get into native apps in the same way.”

L’auteur nous recommanderait-il donc de développer un protocole de communication « custom », plutôt que d’utiliser des standards reconnus et contrôlables (filtrables et analysables par un équipement de sécurité) ? Ca me rappelle les tests d’intrusion de l’an 2000 où des mots de passe transitaient « chiffrés » en base64 sur protocole UDP… n’importe quoi !

Evidemment une application locale sans connexion réseau sera plus sécurisée qu’une application en ligne – mais son intérêt risque d’être rapidement limité, dans mon projet en tout cas…

Pour conclure…

La lecture de ce dernier article m’a achevé (j’espère que vous avez réussi à me suivre jusque là…).

Donc pour revenir à mon projet domotique, c’est sans surprise et avec certaines convictions que je me suis tourné vers une WebApp avec une interface « responsive » en HTML5, jQuery et css3 pour interagir avec les API du RPi.

Je pense que les bonnes pratiques de sécurité suivantes seront suffisantes « eu égard à la sensibilité de mon application » :

  •  Maitrise des clients grâce à l’authentification forte (possession du périphérique + protection par secret utilisateur).
  •  Révocation possible d’un client compromis (ex : vol du périphérique)
  • Aucune donnée locale stockée sur le périphérique

Contrairement à la plupart des applications publiques disponibles pour le RPi qui conservent localement des accès SSH vers le RPi 

  • Respect des pratiques élémentaires en termes de sécurité de développement

Vigilance particulière sur les protections contre les attaques XSS / Cross Domain / Cross Site Request Forgery (HTML5 introduit un risque nouveau avec la possibilité de passer outre les contrôles sur la Same Origin Policy – voir ici pour le florilège d’attaques possibles en HTML5 : http://html5sec.org/ ).

  • Journalisation avancée
  • Alerting en cas d'anomalie

Me voilà paré pour les froides journées d'hiver !

Le thermostat Z-Wave avec la température de consigne (20°).

Thermostat Z-Wave

Le "thermomètre digital" avec la consigne de 20° et la température ambiante de 19,9°

Pour la "sexitude" on repassera :)

Thermomètre digital 2

Pour voir les épisodes précédents : épisode 1 ; épisode 2

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