Après un certain temps avec le Raspberry Pi 2 Model B v1.1., J'ai les préoccupations suivantes?

1. Je sais qu'il est axé sur l'amélioration des secteurs éducatifs vulnérables, mais il est possible de vendre un produit, basé sur le RPi ?. Pour gagner de l'argent avec ça?. Devenez zillionaire avec ça?.
2. Comment dois-je protéger un développement, disons, je ne veux pas que quelqu'un prenne ma carte SD RPi, la duplique et ait ses propres répliques ?. Mon alternative actuelle est de remplir le port SDCard avec de la superglue :). Un autre choix pourrait amener le RPi à envoyer un ping à un serveur de licences en ligne, ce qui nécessiterait bien sûr une connexion WiFi . Ou un ID HASH matériel (cela devrait être une meilleure réponse, je suppose ...)
3. J'ai vérifié qu'il existe également des mécanismes pour récupérer l'installation même si vous n'avez pas la racine, en montant la carte SD. Encore une fois, ma meilleure solution est l'approche superglue ....

Merci d'avance.

Si vous êtes vraiment soucieux de protéger votre propriété intellectuelle, vous pouvez combiner votre application basée sur Rapberry Pi avec un microcontrôleur externe personnalisé (MCU comme AVR, PIC, 8051 ...) basé sur une clé matérielle (connectée à Pi via USB, RXTX, I2C, SPI, 1 fil ...). Par exemple, l'application côté Pi génère un nombre aléatoire qui est envoyé au MCU, décodé et renvoyé comme clé de déverrouillage pour décrypter quelque chose d'important. Ensuite, vous avez également une fonction importante exécutée directement dans MCU (vous passez simplement des paramètres et obtenez le résultat de MCU). Vous pouvez imaginer comment cela augmenterait la difficulté de craquage pour un pirate par ordre de grandeur, car ses connaissances devraient être beaucoup plus larges que d'habitude. Il n'y a pas de protection parfaite, mais si vous voulez vraiment en faire un défi, cela pourrait être une solution.

1. Je pense que c'était l'idée avec le module de calcul tout au long. Faire un profit ne devrait pas être un problème.

2. / 4. L'option superglue est probablement un bon compromis. En fin de compte, vous ne pouvez pas vaincre un attaquant avec un accès physique à l'appareil. Jetez un œil aux consoles de jeux qui ont probablement investi des millions dans l'infrastructure DRM et elles finissent toutes par tomber. Dans un esprit différent, vous pouvez également adopter l'ouverture et vendre une version de développement de votre produit et inclure une sorte de SDK. Les commentaires que vous obtenez d'un groupe d'utilisateurs axés sur la technique peuvent être précieux et fonctionner dans votre intérêt.

Bien que cette pratique perd définitivement de sa couverture, vous seriez étonné par la quantité de connecteurs USB collés sur les ordinateurs de bureau dans les environnements de bureau d'entreprise. Et je parle ici de grandes sociétés multinationales.

Mais maintenant sur le sujet ...

Pour les projets commerciaux où la protection IP est un facteur majeur, le Pi est idéal pour le prototypage précoce / preuve de concept au mieux. Même si la protection ne serait pas un problème, les déploiements du Pi à plus grande échelle ne sont pas à mon humble avis la meilleure solution - pour un certain nombre de raisons que j'ai décrites dans un fil précédent sur ce forum.

Il n'y a aucun système sûr contre l'ingénierie inverse / le piratage / la reproduction. Tout système est exploitable. Chaque système a cependant un score de pénétration. Avec son approche ouverte et sa carte SD externe, le Pi en a une très basse. Une carte matérielle approuvée par les militaires conçue sur mesure avec un SoC personnalisé, des composants en sandwich et un PCB multicouche en combinaison avec un chargeur de démarrage personnalisé, le cryptage matériel aura un score plus élevé.

À cela s'ajoute le facteur de déploiement. Plus votre marché est large, plus il deviendra intéressant pour les gens de s'introduire et de voler votre technologie.

Si le matériel est votre résistance dans toute l'installation et que la protection de votre technologie est un facteur majeur, je ne pense pas que le Pi soit le produit qu'il vous faut. Si votre matériel est un facilitateur pour la vente de services, la protection de la technologie devrait peut-être être effectuée côté serveur plutôt que côté client.

Nous utilisons le Pi pour vendre de tels services. Notre logiciel sur le Pi a un niveau de protection élevé, nous utilisons une application C compilée, verrouillée sur le numéro de série MAC et / ou CPU. Mais à la fin, sans notre côté serveur, même le code source est pratiquement inutile.

Vous pouvez utiliser un ferroutage à l'intérieur de la framboise avec une clé de cryptage. Il existe quelques appareils commerciaux sur le marché. J'ai utilisé ce logiciel de protection série pour Raspberry Pi , qui fonctionne très bien.

Rendez-le open-source

Sérieusement, n'essayez pas de le protéger contre la copie. Rendez-le open-source. Si possible, laissez les autres rejoindre votre projet.

Ensuite, facturez les services. Vous pouvez faire des seaux d'argent si vous le faites bien.

Red-had le fait comme ça et quelques autres sociétés. Ils se portent tous bien et se développent.

Quelques cents à moi:

1. Ne créez jamais de solution autour de scripts pouvant être lus directement.
2. Fonctionnalités de répartition en termes de multiples logiciels / processus et matériels.
3. Ajoutez une dépendance "fonctionnelle" du matériel de lecture.
4. Ajoutez un lecteur de carte à puce et vendez la carte à puce «enabler» avec votre produit.
5. Avoir un serveur de licences
6. Avoir un compteur d'utilisation en EEPROM !!! Et il devrait y avoir un moyen de "recharger" en ligne .. ;-)

...

En tant que protection d'entrée de gamme, il existe un ID de carte SD unique sous /sys/block/mmcblk0/device/lequel n'est pas cloné par un logiciel de clonage d'image de disque typique. Cela a l'avantage de ne pas nécessiter un appareil séparé pour contenir l'identifiant unique et fonctionne plutôt bien comme une deuxième couche de protection après la super-colle. Cela arrêtera au moins les personnes capables de simplement cloner la carte SD.

Une autre astuce concernant la protection à l'aide des identifiants est d'éviter d'utiliser une simple vérification, c'est-à-dire

if(readID() != 0xDEADBEEF) exit();

Des vérifications simples comme celle-ci sont faciles à découvrir (soit en recherchant l'ID connu, soit en surveillant les appels à exit()) et à supprimer. Une bien meilleure approche consiste à impliquer l'ID comme constante dans les calculs. Autrement dit, au lieu de i++quelque part dans votre code, vous écrirez

i = i + readID() - 0xDEADBEEF + 1;

Cela sera beaucoup plus difficile à découvrir, car l'ID exact n'apparaîtra pas dans votre code mot à mot ( 0xDEADBEEF + 1 == 0xDEADBEF0), et inspecter tous les appels exit()ne révélera pas non plus l'emplacement de votre code de protection. Au lieu de cela, votre code plantera simplement sur un système avec le mauvais ID, et l'attaquant devra déboguer la logique de votre application pour comprendre et résoudre le problème.

En utilisant un composant externe, je voulais dire qu'un composant de sécurité résoudrait ce problème. Si vous pensez vraiment que votre idée est géniale et vaut un coût supplémentaire pour le faire, je vous suggère d'utiliser un MCU / CPU professionnel pour le faire. Comme la série Broadcom BCM58101, pas vraiment rentable et peu conviviale pour un nouvel utilisateur, mais un niveau de sécurité élevé peut également protéger votre idée / conception.