Comment puis-je protéger les logiciels sur le Pi pour une utilisation commerciale?

Je voudrais utiliser le Raspberry Pi dans un produit commercial, mais je voudrais empêcher la rétro-ingénierie du logiciel sur l'appareil. Le logiciel en question serait écrit en Ruby. Je suppose que l'utilisateur final a un accès physique à la carte SD et qu'il est suffisamment intelligent pour obtenir un accès root au Pi.

Selon moi, les options peuvent inclure:

• Crypter une partie (ou la totalité) de la carte SD
• Obscurcissez le code Ruby ou compilez-le en bytecode (JRuby ou Rubinius)

Le chiffrement serait la meilleure solution, mais je ne peux pas penser à un moyen de déchiffrer sans demander à l'utilisateur la clé. L'obscurcissement du code est certainement possible, mais moins sûr dans mon esprit.

Est-il possible de crypter une partie de la carte SD sans demander à l'utilisateur une clé pour la décrypter? Ou existe-t-il un meilleur moyen de s'assurer que le code n'est accessible que sur l'appareil souhaité?

Bien sûr, il est possible de décrypter les fichiers / conteneurs / etc cryptés. sans demander de mot de passe. Il suffit de stocker le mot de passe (crypté) sur la carte SD et de l'utiliser pour décrypter vos données. Par exemple, une openssldémonstration simple pourrait être:

openssl enc -a -e -salt -aes-256-cbc -pass pass:abc123 -in /tmp/plaintext.txt -out /tmp/ciphertext.enc

openssl enc -d -a -aes-256-cbc -pass pass:abc123 -in /tmp/ciphertext.enc

Le cryptage serait effectué lors de l'installation du logiciel sur le Pi, et le décryptage serait effectué au moment de l'exécution, éventuellement dans la RAM. Par exemple, le mot de passe peut être une combinaison d'un certain numéro de séquence pseudo-aléatoire (connu de vous) et du numéro de série du Pi spécifique obtenu à partir de a cat /proc/cpuinfo. Ensuite, vous devez trouver un emplacement convenablement caché pour stocker ce numéro pseudo-aléatoire qui est à toutes fins utiles " le mot de passe " et donc le point faible de tout le mécanisme de cryptage. Par exemple, un secteur de rechange sur la carte SD serait le choix typique, mais vous pouvez même l'intégrer dans l'un de vos exécutables.

Dans tous les cas, votre meilleure option est à la fois de crypter et de compiler votre logiciel, pour ajouter différentes couches d'obscurcissement à votre logiciel.

Enfin, si votre logiciel a besoin d'une connexion Internet, vous pouvez même demander au Pi de saisir le mot de passe à chaque fois. Vous devrez toujours masquer le mot de passe dans la connexion, vous devrez également l'utiliser httpset vous devrez vous protéger contre les attaques de réponse, en utilisant l'heure actuelle comme saltpour le cryptage.

Vous disposez de nombreuses options (bon marché) pour sécuriser vos logiciels. Mais vous devez savoir que si votre logiciel atteint un certain seuil de popularité bien défini, il sera à coup sûr fissuré, même si vous investissez des sommes substantielles dans sa protection.

Pratiquement, si le code et les clés sont sur une machine de carte SD, ils seront en mesure de le décompiler, ils seront en mesure de découvrir les clés et ils le seront en mesure d'extraire les données sensibles.

C'est comme le cryptage de films, un DVD doit inclure toutes les informations nécessaires pour décrypter le film afin qu'il puisse être affiché au spectateur, de sorte que tous les mécanismes de protection contre la copie de films sont finalement condamnés.

Le mieux que vous puissiez faire est de modifier l'économie de l'ingénierie inverse de votre produit.

Le chiffrement et / ou l'obscurcissement en vaut-il la peine?

Maintenant que nous avons établi qu'il n'y a aucun moyen de se protéger complètement, les questions deviennent

1. Quelle est la probabilité que cela se produise?
2. Quelle est la valeur pour quelqu'un d'autre de votre algorithme et de vos données?
3. Quel est le coût pour eux d'acheter une licence pour utiliser votre logiciel?
4. Quel est le coût pour eux de répliquer votre algorithme et vos données?
5. Quel est pour eux le coût de l'ingénierie inverse de votre algorithme et de vos données?
6. Quel est le coût pour vous de protéger votre algorithme et vos données?

Si ceux-ci produisent un impératif économique important pour protéger votre algorithme / vos données, alors vous devriez envisager de le faire. Par exemple, si la valeur du service et le coût pour les clients sont élevés, mais que le coût de la rétro-ingénierie de votre code est bien inférieur au coût de développement lui-même, alors les gens peuvent l'essayer.

Donc, cela mène à votre question

• Comment sécurisez-vous votre algorithme et vos données?

Obfuscation

L'option que vous proposez, obscurcissant le code, dérange les aspects économiques ci-dessus - elle essaie d'augmenter considérablement le coût pour eux (5 ci-dessus) sans augmenter considérablement le coût pour vous (6). Le problème est que, comme avec le cryptage DVD, il est voué à l'échec et s'il y a suffisamment de différence entre 3, 4 et 5, alors finalement quelqu'un le fera.

Une autre option pourrait être une forme de stéganographie , qui vous permet d'identifier qui a déchiffré votre code et a commencé à le distribuer. Par exemple, si vous avez 100 valeurs flottantes différentes dans vos données et qu'une erreur de 1 bit dans le LSB de chacune de ces valeurs ne poserait pas de problème avec votre application, encodez un identifiant unique (pour chaque client) dans ces bits . Le problème est que si quelqu'un a accès à plusieurs copies de vos données d'application, il est évident que cela diffère, ce qui facilite l'identification du message caché.

protection

La seule option vraiment sécurisée consiste à fournir une partie critique de votre logiciel en tant que service , plutôt que de l'inclure dans votre application.

Conceptuellement, votre application collecterait toutes les données nécessaires pour exécuter votre algorithme, les regrouperait sous forme de demande à un serveur (contrôlé par vous) dans le cloud , votre service calculerait ensuite vos résultats et les transmettrait au client, qui l'afficherait.

Cela conserve toutes vos données et algorithmes propriétaires et confidentiels dans un domaine que vous contrôlez complètement, et supprime toute possibilité pour un client d'extraire l'un ou l'autre.

L'inconvénient évident est que les clients sont liés à votre prestation de services, sont à la merci de vos serveurs et de leur connexion Internet. Sur le plan positif, ils sont toujours à jour avec des corrections de bugs. Malheureusement, de nombreuses personnes s'opposent au SaaS pour exactement ces raisons.

Ce serait une étape énorme à franchir, et pourrait avoir un coût énorme 6 ci-dessus, mais c'est la seule façon que je peux voir pour garder votre algorithme et vos données complètement sécurisés .

J'ai récemment inventé une solution très élégante à ce problème insoluble. Il a été inspiré par cette bande dessinée xkcd:

Donc, la solution est appelée super glue . Si une carte SD superglue sur le PI, il sera presque impossible d'extraire la carte sans l'endommager.

Vous pouvez même utiliser un disque SSD externe, crypté avec un mot de passe stocké sur SD et vous sentir en sécurité!

La compilation en bytecode serait le meilleur répulsif. En ce qui concerne le cryptage, les logiciels peuvent être stockés dans le volume TrueCrypt, mais uniquement si l'utilisateur n'a pas obtenu l'accès root; il n'y a tout simplement aucun moyen de stocker en toute sécurité le mot de passe car la mémoire / le disque peut être vidé à tout moment pour inspection. Même l'aide d'appareils sécurisés (cartes à puce) ne ferait pas grand-chose, si le logiciel s'exécute là où l'utilisateur a une pléthore d'utilitaires Linux. Pour autant que je sache, le démarrage sécurisé n'est pas une option sur R-Pi qui empêcherait l'utilisateur de bricoler à l'intérieur du système d'exploitation.

Si vous voulez faire une véritable application commerciale, alors le Pi, tel qu'il est dans sa forme d'utilisateur final, n'est pas bon pour vous!

Vous devrez concevoir votre propre PCB, utiliser le processeur qui se trouve sur le Pi par exemple et intégrer une mémoire flash sur le PCB.

1. Écrivez un micrologiciel propriétaire pour le BCM qui a généré un code de connexion unique basé sur un algorithme top secret qui ne peut être utilisé que dans les 10 prochaines secondes.
2. Compilez votre propre noyau avec votre logiciel propriétaire et activez certaines fonctionnalités Linux qui vous permettent de monter la racine à partir d'un fichier chiffré sur le flash, qui contient une autre partition chiffrée avec votre logiciel. (Double protection)
3. Votre micrologiciel BCM générera une clé d'authentification top secret une fois désactivée basée sur des algorithmes intelligents ou des clés publiques et la transmettra à votre noyau Linux personnalisé, qui chargera la partition racine chiffrée et fera plus de choses cryptographiques pendant le démarrage pour charger votre lecteur logiciel chiffré dans l'image cryptée.

CONSEILS

• Les bonnes clés d'authentification ne comptent pas de 8 à 16 caractères.Il est important de fournir des clés d'authentification de 256/512 octets en utilisant plus de symboles système (HEX) et moins de caractères (ASCII).
• N'utilisez pas AES, TKIP car il se fissure facilement
• À ce jour, le cryptage Whirlpool est parmi les plus compliqués à résoudre à l'aide de clés 256/512
• Même si un pirate peut retirer le lecteur flash ou vider le contenu. votre logiciel est crypté deux fois.
• S'ils interceptent la clé d'authentification, il sera très difficile de sortir du firmware (car le BCM peut empêcher les vidages de firmware)
• Certaines roms flash intelligentes ont également une fonction pour empêcher les vidages de la mémoire complète.
• Si vous concevez un PCB, vous implémenterez (comme Dell et Apple) des puces de sécurité qui fournissent toutes vos données et clés de chiffrement et empêchent les tentatives de bruteforce. Certains Dell ont un système d'autodestruction à usage militaire. Si vous entrez un mot de passe BIOS incorrect 2 fois, il efface les disques avec des bombes à dispersion. Vous pouvez implémenter la même chose si vous détectez des manipulations de clé d'authentification.

Fin de la journée. Le Raspberry Pi est destiné à des fins éducatives pour que les enfants apprennent à utiliser Linux et à écrire certains programmes.

Il n'est pas adapté à une utilisation commerciale de haut niveau. Vous devez créer votre propre appareil et créer vos propres systèmes de protection. Parce que si seulement vous et personne d'autre ne savez comment vous protégez vos informations de propriété, les chances que quelqu'un les pirate en utilisant un exploit ou une brute connus sont de 0,001%

ALTERNATIVES

• Écrivez votre logiciel afin qu'il puisse être compilé et déployé sur le système cible dans un format binaire. Exemple EXE pour Windows qui s'exécute sur .NET, JAR pour Java ou (Pas sûr sous Linux, C ++?)
• Rappelez-vous, meilleure est la sécurité que vous souhaitez - Plus vous allez devoir dépenser pour cela. Il n'y a aucune exception.

L'une des solutions consiste à utiliser l'adresse MAC du RaspberryPi qui est presque unique pour un Pi donné. Vérifiez cette adresse dans votre code et fournissez la version compilée. Cela rendra la rétro-ingénierie difficile.

Pour les personnes qui copient aveuglément la carte SD sur une nouvelle, cela ne fonctionnera pas pour eux sur un autre Pi. Cela éloignera la grande majorité des personnes qui volent votre logiciel. D'autres qui sont assez intelligents pour casser cela peuvent être assez intelligents pour refaire le logiciel, ils ne sont pas nombreux et je ne pense pas qu'ils nuiront à vos ventes.

Vous pouvez utiliser une solution basée sur le ferroutage: Protection série logicielle pour Raspberry Pi

Pourquoi ne pas ajouter un flash basé sur SPI à votre carte opérateur et y stocker votre code? J'envisage cette option pour mon propre produit. Dans le cas où la SD est corrompue, je veux que l'utilisateur final puisse en écrire une nouvelle, qui comprend un raspbian personnalisé, et le code pour monter le flash SPI et exécuter l'exécutable.

Une autre option consiste à stocker une clé de chiffrement dans votre RTC. La plupart des puces RTC ont un peu de stockage et elles pourraient être préprogrammées avec la clé qui permet de déverrouiller et de monter l'exécutable depuis SD ou depuis SPI flash.

Je crois que tous les processeurs utilisés dans la gamme de Raspberry Pi prennent en charge leur propre démarrage sécurisé. Je crois qu'il faut 12 volts pour reflasher les 4,8,16,32 ou 64K de flash interne ou EEPROM que le pi lui-même n'a pas. De leur, vous pouvez configurer la zone de confiance avec votre code afin que toutes les bonnes choses ne soient pas visibles. Je comprends également que les deux formes de RAM statique ne sont stables que pour un nombre donné de réécritures. Ma première étape serait d'avoir un CPU de rechange et d'essayer de reflasher cette mémoire de démarrage sécurisée pendant quelques heures ou jours. Finalement, tous les bits deviennent fixes pour que personne d'autre ne puisse modifier votre code et selon le produit réel, vous pouvez périodiquement demander une identification à 2 facteurs (comme les banques) pour que le produit crache un code et que le code de réactivation soit envoyé à l'adresse e-mail. Si vous modifiez un peu le pi, Je crois que ARM a également un CPUID, donc il existe un certain nombre de niveaux de sécurité que vous pouvez choisir. Je veux dire, vous pouvez également offrir un SMS à un numéro spécifique. Beaucoup de façons.