11

After a time with the Raspberry Pi 2 Model B v1.1., I have the following concerns:

  1. I know it is focused to enhance vulnerable educational sectors, but is it possible to sell a product, based on the RPi? To make money with it? Become zillionaire with it?
  2. How should I protect a development, let's say, I don't want somebody to take my RPi SD Card, duplicate it, and have their own replicas? My current alternative is to fill the SDCard port with superglue. Another choice could make the RPi to ping a license server online, which of course would require a WiFi connection. Or a Hardware HASH ID (This should be a better answer I guess...)
  3. I have checked there are also mechanisms to recover the installation even if you do not have the root, by mounting the SD Card. Again, my best solution is the superglue approach....
vvvvv
  • 299
  • 1
  • 2
  • 12
Brethlosze
  • 249
  • 3
  • 11

8 Answers8

8

If you are really concerned about protecting your intelectual property then you can combine your Rapberry Pi based application with some external custom made micro controller (MCU like AVR, PIC, 8051...) based hardware key (connected to Pi via USB, RXTX, I2C, SPI, 1wire...). For example, Pi side application generates a random number which is sent to MCU, decoded and sent back as an unlock key to decrypt something important. Then additionally you have some important function executed directly in MCU (you just pass parameters and get the result from MCU). You can imagine how that would raise cracking difficulty for a hacker in order of a magnitude, since his knowledge would have to be much wider then usual. There isn't a perfect protection, but if you really want to make it a challenge then this could be a way to go.

avra
  • 1,273
  • 8
  • 9
5

  1. I think that was the idea with the compute module all along. It should not be a problem to turn a profit.

  2. / 4. The superglue option is probably a good tradeoff. Ultimately you cannot defeat an attacker with physical access to the device. Have a look at game consoles which have probably millions invested in DRM infrastructure and they all eventually fall. In a different spirit, you could also embrace openness and sell a development version of your product and include some kind of SDK. The feedback you get from a technical focused user group might valuable and work in your interest.

Ghanima
  • 15,958
  • 17
  • 65
  • 125
user1217949
  • 827
  • 2
  • 9
  • 14
4

While this practice definitely is loosing coverage, you'd be astonished by the amounts of USB connectors that have been glued down on desktop machines in corporate office environments. And I'm talking large multinational corporations here.

But now on topic...

For commercial projects where the IP protection is a major factor, the Pi is good for early prototyping / proof of concept at best. Even if protection would not be an issue, deployments of the Pi on a larger scale is IMHO not the best solution - for a number of reasons I described in an earlier thread on this forum.

There is no system safe against reverse engineering / hacking / reproducing. Any system is exploitable. Every system however has a penetration score. With its open approach and external SD card, the Pi has a very low one. A custom designed military-approved hardware board with custom SoC, sandwiched components and multi layered PCB in combination with a custom bootloader, hardware encryption will have a higher score.

On top of that there is the deployment factor. The wider your market is, the more interesting it will become for people to break in and steal your technology.

If the hardware is your piece of resistance in the whole setup and protecting your technology is a major factor, I don't think the Pi is the product for you. If your hardware is a facilitator for selling services, perhaps protecting technology should be done on the server side rather than on the client side.

We use the Pi for selling such services. Our software on the Pi does have a raised level of protection, we're using a compiled C application, locked on MAC and/or CPU serial number. But at the end, without our server side, even the source code is virtually useless.

Community
  • 1
EDP
  • 1,691
  • 1
  • 14
  • 24
2

You can use a piggy-back inside raspberry with an encrypt key. There are a couple commercial devices on market. I used this Software Serial Protection for Raspberry Pi, which works very well.

Paulo Arede
  • 29
  • 1
2

Make it open-source

Seriously don't try to copy-protect it. Make it open-source. If possible, let others join your project.

Then charge for services. You can make buckets of money if you do that right.

Red-had does it like this and a few other companies. They are all doing well and are growing.

MadMike
  • 603
  • 5
  • 19
2

As an entry-level protection, there's a unique SD card ID found under /sys/block/mmcblk0/device/ which is not cloned by typical disk image cloning software. This has the advantage of not requiring a separate device to hold the unique ID and works pretty well as a second layer of protection after the superglue. It will at least stop people who are capable of simply cloning the SD card.

Another tip regarding protection using IDs is to avoid using a simple check, i.e.

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

Simple checks like that are easy to discover (either by searching for the known ID or by monitoring calls to exit()) and remove. A much better approach is to involve the ID as a constant in calculations. That is, instead of i++ somewhere in your code you will write

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

This will be much more difficult to discover, as the exact ID will not appear in your code verbatim (0xDEADBEEF + 1 == 0xDEADBEF0), and inspecting all calls to exit() also won't reveal the location of your protective code. Instead, your code will simply crash on a system with the wrong ID, and the attacker will have to debug your application's logic to understand and fix the problem.

Dmitry Grigoryev
  • 28,277
  • 6
  • 54
  • 147
1

Few cents of mine:

  1. Never create a solution around scripts which can be directly read.
  2. Breakdown functionalities in terms of multiple software/processes and hardware.
  3. Add some read hardware "functional" dependency.
  4. Add smart card reader and sell "enabler" smart card with your product.
  5. Have a license server
  6. Have a usage counter in EEPROM!!! And there should be some way to "recharge" online.. ;-)

...

tlhIngan
  • 3,372
  • 5
  • 21
  • 33
Jatin Gandhi
  • 11
  • 1
1

Using an external component, I meant security component would solve that issue. If you really think your idea is great and worth extra cost to do so, I would suggest you to use some professional MCU/CPU to do so. Like Broadcom BCM58101 series, not really cost effective and not friendly to a new user but high security level can also protect your idea/design.

Benjamin LIiiiiiiii
  • 11
  • 1