Programatically lock SD Card to hardware unit?

[JFarns]

I'm trying to figure out if there is a way to lock the software (SD Card) to a particular hardware unit. For example, if there is way to programatically get a serial number or something from the board, ARM, etc.

Is this possible? Or does anyone have a better/different idea?

Thanks

[SeanD]

Yes it could be done, and reasonably easily but I think it would bet better to first understand what you are trying to achieve as that would control the range of options and the limitations of each one.  The simplest will be a hardware hash as I have seen nothing that indicates that the SoC has a secure element.

[JFarns]

Thanks for the response. Basically, if one were to sell a Raspberry Pi based device, there wouldn't be much to stop an unscrupulous user from just making copies of the SD card, get their own devices and start selling their own. Since everything has to be on the SD card as there is no flash, it is a possibility, though I don't know how likely. If there were a way to lock the software to the hardware that would make creating copies much more difficult.

[Vindicator]

Could it be unscrupulous to lock a device that is intended to be open source for your own profitability instead of developing your own device with your own money/time/labor for said purpose.

Just a thought.

[liz]

We're all for people using Raspberry Pis in their own products. I've said it before, but it bears repeating: we think entrepreneurship makes the world spin. It's a way to create individual and community social mobility, it creates jobs, and does good things for the general economy. We'd be grateful if people making successful products with the Raspberry Pi choose to donate some money to the project, but we'll also be really pleased just to see people making businesses run with the Raspberry Pi.

[toxibunny]

Doesn't seem all *that* unscrupulous to me, not wanting your software to be copied...

[bredman]

You could query the Ethernet port for its MAC address and use this as the board identifier.

But you will have to hide the logic deep deep deep within your code. Hackers are very good at finding this type of lock and working around. You will have more problem securing your lock than implementing it.

[meltwater]

Can't you change the MAC address?

AFAIK, the boards have their own serial number in "write only memory"(...ok write once read many, but that's how I recall it is there).  Chances are you could use that.  In theory you could generate a code from the serial number and then an unlock key from that.

Alternatively, there are id's within the sd-card which might be usable.

However, what happens if the user wants to swap to a different RPi or switch between two different ones, or change to a bigger SD card etc.

There are always ways to crack these things, but as long as it is a little harder than simply cloning the card it is a start.

[mccp]

One of the really interesting things about the Raspberry Pi is the resonance with the educational software market of the 1980's.

This question is exactly the same question that we had to answer when publishing software for the BBC micro that was sold to schools. My first proper job was programming for an educational software publisher that was responsible for some of the most popular titles and we were constantly surprised at the willingness of teachers to simply make copies of software rather than buying copies.

We ended up with a clever disc protection system that relied on the Intel 8271 disc controller reading random data if the clock signal recorded on a floppy disc sector was interrupted. Pretty much impossible to copy - to the extent that we had some difficulty finding a factory able to duplicate our discs. Then we had to re-engineer it for the Western Digital FD1771. And then again for ADFS. What fun we had .

I'd have to say that in the end, it probably wasn't worth it. We realised that those people who made copies, didn't generally go out and buy a pukka copy if they couldn't make one. We also found that we had to provide more support because users couldn't easily make a backup.

I think that these days I would probably not bother with any kind of protection - especially anything that relies on particular hardware.

Instead, make sure that you have a very accessible sales route - i.e. an up-to-date website, get your users to register themselves if they buy your software and give them plenty of free updates and support. If you spend your time and effort worrying about the people who are prepared to pay you for your software, rather than the ones who are happy to rip you off, you will have more fun and probably be more successful.

[meltwater]

That is a fair point, those who are going to spend the time cracking it aren"t planning on buying.  Back in the micro days, all sorts of methods were used (and cracked) and the same still happens, even to the big names who spend millions on it.

But I guess the purpose is to stop someone from doing it wholesale and re-branding it, but then it should be easy to prove by that point what they have done, and handle it suitably through legal action instead.

Chances are, something fairly simple should be enough, without punishing the user for buying it (like most DRM does).

Code Obfuscation is probably more useful since it'll protect any branding you build into it, so you can keep your ownership.

[grumpyoldgit]

Am I missing something? I thought the OS was going to be Linux based and therefore open sourced!

[bredman]

Linux uses the GPL license. This means that it is possible to add commercial products on top of it, as long as you are careful.

You are not required to publish the source code of the commercial product if you use only the published APIs provided by Linux.

[rew]

Or you could write your own proprietary OS.

As a side note, I seem to remember vaguely that the raspberry-pi doesn't have a place to store the ethernet mac. But this contradicts the quote from the foundation that you would get a board with a mac with a lot of zeroes in it if you buy one of the auctioned beta boards.

[MarkA]

Hi all, I tend to lurk more than post, so just sticking my head over the parapet for a short time.

In my experience, people are lazy, and this can be used to your own advantage. Make the sales route very very simple, and give a little extra just to sweeten the deal.

(think download singles vs CD sales)

Would I buy a locked down machine with little support, or one where the manufacturers are very proactive, offer cheap/free upgrades and constantly develop their products, possibly with a user community behind it?

Personally I'd go for the latter, and maybe even pay a little more for it, knowing that the product will remain supported. What's more, I'd tell my friends and be loyal to the brand for future purchases.

Just my thoughts on the matter.

[plugwash]

One option if building a custom device round the Pi is to lock the software to the custom bit of the device.

Consider for example that many devices are likely to use a PIC or similar as an IO expander (there isn't much IO on the Pi itself). You can set the code protect configuration bit on the pic and perform some small but critical parts of your operation on the PIC rather than the pi.

[graham_chow]

You could also araldite the card to the device.

[mccp]

Part of the problem with a device like the Raspberry Pi is that, by design, it is very open. This makes it straightforward to crack any protection system that is required to communicate with another device.

In the end you need to think of this as a commercial problem, not a technical one. What are you likely to lose? If you really do have the killer app for Raspberry Pi and you charge a worthwhile price for it, you'll probably find that others publish very similar - maybe better - versions and sell them cheaper. In that case you would be much better off investing the effort in a superb end-user experience (support/updates/etc) than investing in a crack-proof protection system.

If you are worried that your users will simply make copies of your application, then try and work out how many of those copies will actually displace sales - and then work out if the marketing value is less than the lost sales.

[gjs]

graham_chow said:


You could also araldite the card to the device.


May I just say, I think that is a brilliant solution!

Time to implement: 10 seconds

Cost to implement: 1 cent

Hack resistance: good enough

Brilliant!

[mccp]

graham_chow said:


You could also araldite the card to the device.


Made me laugh, but I can probably still copy the contents of the file system over Ethernet so no cigar .

[JFarns]

Wow, this thread sort of blew up with a deeper discussion of open source philosophy. Thanks for all the replies. For those questioning the motives and how it relates to an open source platform, in this instance the value added in the commercial product is the software. A business would have a hard time being successful just marking up a Raspberry Pi with very simple software and little added value. If commercially successful, clones would undercut them very quickly.

As some as commented, it is a question of the effort required as compared to how likely/hurtful illegal copies would be. It is pretty much impossible to put it on total lock down, but preventing a simple SD card clone would probably be good enough. And while IP infringement/copying can be dealt with in the courts that can by very messy and difficult. An ounce of prevention is worth a pound of cure. The point is not to provide an airtight, locked down system. But not spending a little bit of time to try to secure the software would seem foolish.

Thanks.

[gjs]

mccp said:


graham_chow said:


You could also araldite the card to the device.


Made me laugh, but I can probably still copy the contents of the file system over Ethernet so no cigar .


Yes, but with some effort and linux know-how etc, hence my 'good enough' rating.  It just struck me as a wonderfully elegant, simple solution.

(Also, I won't mention that I spent some time the other day looking for a SD card that can be soldered directly to a PCB to discourage card swapping by end users... )

[SeanD]

plugwash said:


One option if building a custom device round the Pi is to lock the software to the custom bit of the device.

Consider for example that many devices are likely to use a PIC or similar as an IO expander (there isn't much IO on the Pi itself). You can set the code protect configuration bit on the pic and perform some small but critical parts of your operation on the PIC rather than the pi.


This is a very pragmatic and simple way of implementing a secure element and in fact very similar to the TrustZone design that ARM have for the SoC.

I work in commercial software and have been involved in the design and implementation of various forms of software or IP protection over the years. As I think has been said above this is something which we still spend a lot of money on but most of the solutions have been listed above.  Make it easy for people to buy your stuff, give people who have purchased support and entitlements.  The later is actually now one of the most effective but is also quite complex to implement making heavy use of cryptography and a PKI infrastructure coupled with a CDN that costs 8 figures a year to run.  Obviously if your device is stand alone and it has no need to have content fed to it then this does not work, but if it does then this is one of the most effective anti piracy options you have.  Your software is not important, it is the subscription to the feed that is, and the nice thing about that is if it is cracked you can change it.

[hedgehog]

How about encrypting the initramfs/initrd/rootfs with the mac address. Along with a customized kernel to decrypt while it's being read/booted.

You would need to create a custom filesystem per RasPi.

Don't know how easy or effective this would be.

[HansH]

I would be interesting to know how I can get my Pi's serialnumber from it...

Perhaps I will get  no 11

[error404]

hedgehog said:


Don't know how easy or effective this would be.



Not very (for reasonable definitions of 'effective'), I don't think. Any kernel modification must be released under GPL, and due to the boot process of the BCM2835, it's trivial to replace the kernel with one of the user's design (which pulls a small serial-console-starting init from the FAT32 partition or something), then the system is wide open and the cleartext of the filesystems should be easy to get.

You could move up the chain and write a custom bootloader that checks the kernel signature and decrypts it, but again, due to the BCM2835's boot process, the user could easily replace that bootloader with one that has the signature checking removed - among other attacks. Reversing the encryption key generation probably wouldn't be difficult without you going to great lengths to obfuscate it, so then they can do the same kernel replacement attack, or simply use the determined key to try to decrypt the image outside of the host machine.

This does of course assume your product will be using Linux. If not Linux the reversing job will be more difficult because they won't have the source, but the same attack (among others involving a modified bootloader) is possible.

Like any DRM scheme, you're basically just putting speedbumps in the way. Since the 'attacker' must have access to the content you're trying to protect (to execute it...), wasting effort trying to stop them very quickly gets to steeply diminishing returns, and stopping them - or even providing a significant barrier is basically impossible without a secure boot chain - which the Raspberry Pi doesn't offer.

Basically if you want to base your product on the Raspberry Pi hardware I would simply start from the assumption that clones will be easy to create and go from there. Change your business model to accomodate them or give up now. No matter what lengths you go to trying to prevent them, if there's profit in it, they will find a solution, since the old adage about physical access definitely applies here, probably moreso than it does in many other embedded systems due to the way the system boots.

Also I would like to point out that a 'clone' probably doesn't violate your IP unless they are actually using your code. I don't know what you're trying to make here, but unless it is very complex, it'll probably be cloned in the true sense of the word anyway, without any IP rights infringement taking place. Really you should be prepared for this regardless of how strong or weak your protection scheme is.