ejolson
Posts: 4898
Joined: Tue Mar 18, 2014 11:47 am

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 4:11 am

cleverca22 wrote:
Tue Mar 24, 2020 2:37 am
PiGraham wrote:
Mon Mar 23, 2020 8:59 pm
cleverca22 wrote:
Mon Mar 23, 2020 3:49 pm

for the 1st point, you would need to convince whoever is fabbing the RPI board, to not program the signing key in the OTP memory, so you have the ability to put your own key onto it (and double-check if its blank or not first, before bothering them)
If this was available what stops someone else getting such a RPi and putting the same key into it?
if you put a custom signing key into the OTP, then only firmware you approve of (which you signed) can boot on the pi

if you restrict things properly (like a real secureboot setup), then no un-authorized code will ever run on that board, and you can be sure the other OTP values can never be read

and there is already some spare OTP fields for the user to use, which could hold the encryption keys for the main rootfs
While it is great fun to imagine impossibly complicated ways to prevent someone from getting the code in a Pi edition of spy versus spy.

Image
https://en.m.wikipedia.org/wiki/Spy_vs._Spy

The effort to keep the code secret is almost always better spent debugging it.

PiGraham
Posts: 3881
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 8:00 am

cleverca22 wrote:
Tue Mar 24, 2020 2:37 am

if you put a custom signing key into the OTP, then only firmware you approve of (which you signed) can boot on the pi
Are you saying that standard Pi firmware does this already, or is this custom firmware that will only boot a custom kernel?

PiGraham
Posts: 3881
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 8:35 am

Could the contents of the OTP be used as a moderate protection key?

There is a unique serial number, optionally a MAC address, customer data.

https://www.raspberrypi.org/documentati ... /README.md

User avatar
DougieLawson
Posts: 38506
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 8:42 am

cleverca22 wrote:
Tue Mar 24, 2020 2:37 am
PiGraham wrote:
Mon Mar 23, 2020 8:59 pm
cleverca22 wrote:
Mon Mar 23, 2020 3:49 pm

for the 1st point, you would need to convince whoever is fabbing the RPI board, to not program the signing key in the OTP memory, so you have the ability to put your own key onto it (and double-check if its blank or not first, before bothering them)
If this was available what stops someone else getting such a RPi and putting the same key into it?
if you put a custom signing key into the OTP, then only firmware you approve of (which you signed) can boot on the pi

if you restrict things properly (like a real secureboot setup), then no un-authorized code will ever run on that board, and you can be sure the other OTP values can never be read

and there is already some spare OTP fields for the user to use, which could hold the encryption keys for the main rootfs
Why would I want that on a small board computer? What does it give me? Why should the Raspberry Pi Foundation spend their "money for education" on that? What's the USP? My Raspberry is going to cost £40 rather than £35 to cover the development of something that isn't needed.

You are going to have a really hard job convincing me of the business case for this.

Think again.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

I'll do your homework for you for a suitable fee.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

User avatar
rpdom
Posts: 16745
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 9:13 am

DougieLawson wrote:
Tue Mar 24, 2020 8:42 am
Why would I want that on a small board computer? What does it give me? Why should the Raspberry Pi Foundation spend their "money for education" on that? What's the USP? My Raspberry is going to cost £40 rather than £35 to cover the development of something that isn't needed.

You are going to have a really hard job convincing me of the business case for this.
Because a large part of Pi sales go to big businesses for use in commercial products. They may want the ability to lock down their software.

It would have to be an option that can be set, hence using OTP. By default it wouldn't be set.

Profits from commercial sales is one thing that keeps the Raspberry Pi Foundation running.
Unreadable squiggle

ejolson
Posts: 4898
Joined: Tue Mar 18, 2014 11:47 am

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 4:24 pm

rpdom wrote:
Tue Mar 24, 2020 9:13 am
DougieLawson wrote:
Tue Mar 24, 2020 8:42 am
Why would I want that on a small board computer? What does it give me? Why should the Raspberry Pi Foundation spend their "money for education" on that? What's the USP? My Raspberry is going to cost £40 rather than £35 to cover the development of something that isn't needed.

You are going to have a really hard job convincing me of the business case for this.
Because a large part of Pi sales go to big businesses for use in commercial products. They may want the ability to lock down their software.

It would have to be an option that can be set, hence using OTP. By default it wouldn't be set.

Profits from commercial sales is one thing that keeps the Raspberry Pi Foundation running.
Creating hardware that can fully secure software is very difficult. The most one could hope for is
  • Free publicity when a child creates and widely circulates a vulnerability in the security system within weeks.
  • More free publicity a year later when various government agencies threaten the manufacturer with sanctions if they don't provide an official backdoor.
Since hiding the source code makes it difficult for the user to learn from or debug, as already mentioned, this is the opposite of the original learn-through-making niche the Pi was designed for.

cleverca22
Posts: 397
Joined: Sat Aug 18, 2012 2:33 pm

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 5:27 pm

PiGraham wrote:
Tue Mar 24, 2020 8:00 am
cleverca22 wrote:
Tue Mar 24, 2020 2:37 am

if you put a custom signing key into the OTP, then only firmware you approve of (which you signed) can boot on the pi
Are you saying that standard Pi firmware does this already, or is this custom firmware that will only boot a custom kernel?
currently, the official rpi firmware doesnt support secureboot

so you would need to either add it to the open firmware, or convince the rpi foundation to implement it fully

of note, the roku2 used the same bcm2835 as the rpi1, and had a unique signing key for every box, and fully signed boot chain, to prevent any unauthorized code, but it also had an exploit in its GUI that gave you a root shell, where you could then patch, re-sign, and re-flash its own firmware...

PiGraham wrote:
Tue Mar 24, 2020 8:35 am
Could the contents of the OTP be used as a moderate protection key?

There is a unique serial number, optionally a MAC address, customer data.

https://www.raspberrypi.org/documentati ... /README.md
if you dont implement secureboot, then any attacker can just boot plain raspbian on the board, and read the OTP memory, then just manually run your decryption routines with that as an input, and your safe cracks open

User avatar
thagrol
Posts: 2696
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 6:26 pm

PiGraham wrote:
Tue Mar 24, 2020 8:35 am
Could the contents of the OTP be used as a moderate protection key?

There is a unique serial number, optionally a MAC address, customer data.
Nope. Serial numbers and MAC addresses are not unique.

Prior to the 4B all Pi have randomly generated serial numbers. There are enough Pi in the wild that serial number have been duplicated. MAC address(es) on these models are generated from the serial number so is also not unique.

Don't know about the serial number on the 4B but I believe the MAC addresses are set in the OTP at the factory and are no longer derived from the serial number.
Attempts to contact me outside of these forums will be ignored unless signed in triplicate, sent in, sent back, queried, lost, found, subjected to public enquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters

deepo
Posts: 548
Joined: Sun Dec 30, 2018 8:36 pm
Location: Denmark

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 7:21 pm

thagrol wrote:
Tue Mar 24, 2020 6:26 pm
PiGraham wrote:
Tue Mar 24, 2020 8:35 am
Could the contents of the OTP be used as a moderate protection key?

There is a unique serial number, optionally a MAC address, customer data.
Nope. Serial numbers and MAC addresses are not unique.

Prior to the 4B all Pi have randomly generated serial numbers. There are enough Pi in the wild that serial number have been duplicated. MAC address(es) on these models are generated from the serial number so is also not unique.

Don't know about the serial number on the 4B but I believe the MAC addresses are set in the OTP at the factory and are no longer derived from the serial number.
But again as a moderate protection I'd have no problems using serial number.
What are the chances for finding another RPi with the same serial number? Very small I'd think.

/Mogens

PiGraham
Posts: 3881
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 7:28 pm

thagrol wrote:
Tue Mar 24, 2020 6:26 pm
PiGraham wrote:
Tue Mar 24, 2020 8:35 am
Could the contents of the OTP be used as a moderate protection key?

There is a unique serial number, optionally a MAC address, customer data.
Nope. Serial numbers and MAC addresses are not unique.

Prior to the 4B all Pi have randomly generated serial numbers. There are enough Pi in the wild that serial number have been duplicated. MAC address(es) on these models are generated from the serial number so is also not unique.
It doesn't need to be unique, merely not readily available as a duplicate of the target system. Nobody would buy thousands (millions?) of RPi and try them all to find those that match the S/N of the RPi that uns the protected S/W.

Unless entire batches were programmed with the same S/N It would be much less work to hack the protection so the copied program works on any RPi.

cleverca22
Posts: 397
Joined: Sat Aug 18, 2012 2:33 pm

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 7:32 pm

it would be far simpler to just patch the program to not check the serial#

and if your using encryption with the serial# as the key, just read the serial# with a different distro, and decrypt it

the ideas i gave, stop them from even knowing the serial#, so they cant do either of the above

PiGraham
Posts: 3881
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 8:58 pm

cleverca22 wrote:
Tue Mar 24, 2020 7:32 pm
it would be far simpler to just patch the program to not check the serial#

and if your using encryption with the serial# as the key, just read the serial# with a different distro, and decrypt it

the ideas i gave, stop them from even knowing the serial#, so they cant do either of the above
So, we agree that a simple key is very crackable.

But secure boot seems to be about ensuring the (UFEI) firmware only boots into signed code (kernel) but something more is required to secure individual userland applications. How do you leave the platform open to makers and students with full root access and also lock down particular applications in a way that is somewhat hacker-proof?

I'm also wondering how a locked-down kernel sits with open source licences. Users are free to build their own version of the OS from source. How do you keep RPi both open and closed?

User avatar
thagrol
Posts: 2696
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 8:59 pm

cleverca22 wrote:
Tue Mar 24, 2020 7:32 pm
it would be far simpler to just patch the program to not check the serial#

and if your using encryption with the serial# as the key, just read the serial# with a different distro, and decrypt it

the ideas i gave, stop them from even knowing the serial#, so they cant do either of the above
Secureboot is currently a non-starter given the closed source nature of the firmware.

Has no-one done a forum search? This isn't the first time this (and similar) question has been asked.

You've essentialy got the same two options the big boys do: online activation tied to a license key and a hardware hash (though a hardware hash might not be that usefull on a Pi) or a hardware dongle that must be present when your code is run. Or, maybe, a TPM.

It's a trade off. No software is ever going to be secure unless you have full encryption including in RAM and, probably, the CPU caches. There are ways to get back at the code even if that only gives you the assembler rather than the high level source.

You need to decide if the level of protection you can get is worth the effort you need to expend to get it.

edited for tpyos
Attempts to contact me outside of these forums will be ignored unless signed in triplicate, sent in, sent back, queried, lost, found, subjected to public enquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters

cleverca22
Posts: 397
Joined: Sat Aug 18, 2012 2:33 pm

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 10:37 pm

PiGraham wrote:
Tue Mar 24, 2020 8:58 pm
cleverca22 wrote:
Tue Mar 24, 2020 7:32 pm
it would be far simpler to just patch the program to not check the serial#

and if your using encryption with the serial# as the key, just read the serial# with a different distro, and decrypt it

the ideas i gave, stop them from even knowing the serial#, so they cant do either of the above
So, we agree that a simple key is very crackable.

But secure boot seems to be about ensuring the (UFEI) firmware only boots into signed code (kernel) but something more is required to secure individual userland applications. How do you leave the platform open to makers and students with full root access and also lock down particular applications in a way that is somewhat hacker-proof?

I'm also wondering how a locked-down kernel sits with open source licences. Users are free to build their own version of the OS from source. How do you keep RPi both open and closed?
by default, all of the secureboot stuff is disabled on the rpi 1-3, some users have enabled it, but that effectively bricked the pi, due to lack of understanding for signing

the rpi4 required signed SPI firmware to boot, but it doesnt validate the start4.elf stage, so you loose all security

for both, thats "open" enough to allow developers to play and hack with it

if you wanted proper security, you would need a custom signing key, and enable signature checking, so only an authorzed bootcode.bin can run
then bootcode.bin must be modified to maintain the chain of trust all the way to linux (either open firmware, or ask the foundation, as i said earlier)

and then using that secureboot, you can block reads from the OTP, so you can just put something like a luks password in OTP to protect the real app


the biggest blocker for all of that, is getting an rpi where the signing key hasnt been burned into the OTP, so you can burn your own custom key, which only you know, you would need some special request to the place assembling the pi's, to get them to skip a step while assembling it

User avatar
dickon
Posts: 1223
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 10:58 pm

Secure Boot is broadly worthless anyway, because of the problem mentioned above: it requires the *entire stack*[0] to be secure: firmware, bootloader, kernel[1], *anything which may be executed as root*[0] (or equivalent), and anything which can be influenced to execute anything as root.

Now, bear in mind that Windows has an *in-kernel*[0] font renderer (which, much to my aloof amusement, has been exploited in the past[0]), and you can see the futility in the concept. Hollywood liked the idea, because you could have a trusted OS running on some trusted hardware which could be guaranteed not to let *its owner*[0] look at what it was doing when playing back some protected content[0]. And then Microsoft allowed the X-Box to act as an external HD-DVD drive to a Windows host, over ethernet (or wifi; I forget), by punting USB commands over ethernet, *in the clear*[0], which included all the decryption keys[0].

Yeah[0]. Pointless[2].



[0] FFS...
[1] And anything running in kernel context, such as your anti-virus suite; google 'sophail' for much amusement.
[2] See? [0].

trejan
Posts: 1621
Joined: Tue Jul 02, 2019 2:28 pm

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 11:45 pm

dickon wrote:
Tue Mar 24, 2020 10:58 pm
And then Microsoft allowed the X-Box to act as an external HD-DVD drive to a Windows host, over ethernet (or wifi; I forget), by punting USB commands over ethernet, *in the clear*[0], which included all the decryption keys[0].
Eh? You sure about this? You could use the Xbox HD DVD external drive with a PC as it was just USB but I've never heard of them doing it over Ethernet. The player keys for the drive were extracted by patching the firmware.

User avatar
dickon
Posts: 1223
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Destroy pi sd card... On purpose if removed

Tue Mar 24, 2020 11:52 pm

That was the story I heard. The X-Box could be attached as a USB device *over ethernet* -- AIUI -- which meant you could trivially snoop the traffic on the network with the usual tools. The over-ethernet being important because most people have the X-Box in the livingroom and the PC in an office elsewhere.

I may well be wrong, but that was what I remember hearing at the time.

PiGraham
Posts: 3881
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Destroy pi sd card... On purpose if removed

Wed Mar 25, 2020 8:47 am

cleverca22 wrote:
Tue Mar 24, 2020 10:37 pm

by default, all of the secureboot stuff is disabled on the rpi 1-3, some users have enabled it, but that effectively bricked the pi, due to lack of understanding for signing

the rpi4 required signed SPI firmware to boot, but it doesnt validate the start4.elf stage, so you loose all security

for both, thats "open" enough to allow developers to play and hack with it

if you wanted proper security, you would need a custom signing key, and enable signature checking, so only an authorzed bootcode.bin can run
then bootcode.bin must be modified to maintain the chain of trust all the way to linux (either open firmware, or ask the foundation, as i said earlier)

and then using that secureboot, you can block reads from the OTP, so you can just put something like a luks password in OTP to protect the real app


the biggest blocker for all of that, is getting an rpi where the signing key hasnt been burned into the OTP, so you can burn your own custom key, which only you know, you would need some special request to the place assembling the pi's, to get them to skip a step while assembling it
I found this info on verified booting: https://blog.nviso.eu/2019/04/01/enabli ... erry-pi-3/

I can see the sense of it for closed-source OS binaries on controlled hardware, but how is it supposed to work for open source OS on uncontrolled hardware? Anyone can buy a RPi that is not, and should not be, locked down. They can build their own kernels and do what they like so none of this prevents anyone running Raspbian, or another OS, on a clean RPi board.

It works for DRM on particular devices where you want to deny root access and prevent custom kernels running, but that is contrary to the goals for Raspberry Pi, isn't it?

PiGraham
Posts: 3881
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Destroy pi sd card... On purpose if removed

Wed Mar 25, 2020 8:55 am

Here's another crypto add-on option
https://rpi-drm.com/

It looks like it wouldn't be so hard to crack it though. It seems to rely on periodic calls to a DRM static library and your own code handling violations:
Your application needs to start the library and handle “genuine” and “not genuine” cases.
Locate and patch those calls and you don't need the hardware any more.

You can use it to en/de-crypt data so you could make things harder for a cracker but surely still not impossible on an open system like RPi.

LTolledo
Posts: 3076
Joined: Sat Mar 17, 2018 7:29 am
Location: Anime Heartland

Re: Destroy pi sd card... On purpose if removed

Wed Mar 25, 2020 9:32 am

makes me wonder....

:o has there been reported successes in retrieving/extracting data from a physically mutilated microSD card? :shock:
"Don't come to me with 'issues' for I don't know how to deal with those
Come to me with 'problems' and I'll help you find solutions"

Some people be like:
"Help me! Am drowning! But dont you dare touch me nor come near me!"

PiGraham
Posts: 3881
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Destroy pi sd card... On purpose if removed

Wed Mar 25, 2020 9:54 am

LTolledo wrote:
Wed Mar 25, 2020 9:32 am
makes me wonder....

:o has there been reported successes in retrieving/extracting data from a physically mutilated microSD card? :shock:
No doubt a lot can be done with physically damaged cards if the FLASH chip is intact.

https://www.youtube.com/watch?v=jjB6wliyE_Y

Integrated circuits can be de-capped to access the silicon inside and potentially new bod wires can be attached.

But all of this is LOT of work and your precious software would have to be very expensive to justify the work.
If you are selling a product at those sort of prices use a secure hardware platform, not a cheap education/maker product.

LTolledo
Posts: 3076
Joined: Sat Mar 17, 2018 7:29 am
Location: Anime Heartland

Re: Destroy pi sd card... On purpose if removed

Wed Mar 25, 2020 11:47 am

watched the video... the microSD doesnt seem mutilated so it looked possible,
but as @PiGraham mentioned... it will take a LOT of work.... ("a LOT of meticulous hard work" ) could be a better term for it.

so my suggestion is "eventual physical destruction* of the microSD card upon removal" should be what the OP look into.... ;)

* ripped apart.... to pieces...
"Don't come to me with 'issues' for I don't know how to deal with those
Come to me with 'problems' and I'll help you find solutions"

Some people be like:
"Help me! Am drowning! But dont you dare touch me nor come near me!"

User avatar
DougieLawson
Posts: 38506
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Destroy pi sd card... On purpose if removed

Wed Mar 25, 2020 12:12 pm

LTolledo wrote:
Wed Mar 25, 2020 11:47 am

so my suggestion is "eventual physical destruction* of the microSD card upon removal" should be what the OP look into.... ;)

* ripped apart.... to pieces...
Perhaps an adaptation of https://youtu.be/ku9W-pqDLdw
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

I'll do your homework for you for a suitable fee.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

PiGraham
Posts: 3881
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Destroy pi sd card... On purpose if removed

Wed Mar 25, 2020 12:44 pm

LTolledo wrote:
Wed Mar 25, 2020 11:47 am
watched the video... the microSD doesnt seem mutilated so it looked possible,
but as @PiGraham mentioned... it will take a LOT of work.... ("a LOT of meticulous hard work" ) could be a better term for it.

so my suggestion is "eventual physical destruction* of the microSD card upon removal" should be what the OP look into.... ;)

* ripped apart.... to pieces...
That video demonstrates you don't need the SD card contacts intact.

Beyond that how could an SD card be fixed to a Pi to guarantee that accessing it's contacts would destroy the chip?

Well, you can't do that. It's contacts have to connect to the RPi so if nothing else you could always cut the RPi to expose the contacts and read the card that way.

You can only make it too difficult to bother with, given the value of the code you are trying to protect.

Super glue or epoxy are reasonable options, but both can be removed given time and care.

User avatar
thagrol
Posts: 2696
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Destroy pi sd card... On purpose if removed

Wed Mar 25, 2020 1:44 pm

PiGraham wrote:
Wed Mar 25, 2020 12:44 pm
You can only make it too difficult to bother with, given the value of the code you are trying to protect.
Yep. And you need to balnace that against the additional time, effort, and cost to you. Not just in production but in maintenance. A glued in SD card for example means you have to ship ount an entire new unit when it fails.
Attempts to contact me outside of these forums will be ignored unless signed in triplicate, sent in, sent back, queried, lost, found, subjected to public enquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters

Return to “Advanced users”