EDIT: Protecting against cold boot attacks is only a few lines of codes, the performance impact is very low, but the security gain is massive. So the ROI is extremly high and thus it should be implemented.

It's a few lines of code that would be on the SD card. Your attacker has just swapped the SD card, so they only need to use an SD card without that change and you have no gain.
If there is no gain then there is no point in implementing it.

It's a few lines of code that would be on the SD card. Your attacker has just swapped the SD card, so they only need to use an SD card without that change and you have no gain.

Yeah, you're right the code on the SD card would bring no gain. Thats why it must be in the bootrom. To change the bootrom the attacker has to boot the PI with his SD card and while that the RAM content is destroyed.

Hmm, thinking about it, that may not work either.
Given the fact that in the past when you switched RAM vendor you also released a new bootcode.bin, I am guessing RAM is enabled by that file on SD card, and access to it is still disabled when the on-chip bootrom is run.

Can anyone actually explain why this is a valid security issue? In order to do any of the above, you need physical access to the device, in which case all bets are off anyway.

Yeah, you need physical access and zeroing RAM at boottime would prevent this attack reading out the memory. I mean when we say we don't need this feature because when you have physical access all bets are off anyway, then you also don't need a screensaver/lockscreen. User has physical access anyway so all bets would be off anyway.
EDIT: Protecting against cold boot attacks is only a few lines of codes, the performance impact is very low, but the security gain is massive. So the ROI is extremly high and thus it should be implemented.

General consensus here is that this is a non-issue because of the aceess requirements, so I am dubious of any security gain whatsoever. Also, how long does it take to zero 1GB of RAM, given the speed of the SoC, and the speed of the RAM itself?

With regards to screensavers/lockscreen, that comes by default with LCDE, so is included by default.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

General consensus here is that this is a non-issue because of the aceess requirements, so I am dubious of any security gain whatsoever.

You are now saying that if something is not remotely exploitable, it does not count as a security problem.

The security implication is clear.
If the Pi is turned on but on lock screen, and I have encrypted storage (which is standard in operating systems like Android, but also readily available on the Pi, e.g. when using Berryboot it is a matter of clicking the right checkbox during installation), I have the reasonable expectation that even if someone gains physical access to my Pi, he still is not able to access my files.
But it turns out it is still possible to recover the decryption keys from memory.

Also, how long does it take to zero 1GB of RAM, given the speed of the SoC, and the speed of the RAM itself?

It is in the start post.
Half a second.
Naturally you could make it configurable by OTP, if bootrom was able to access RAM.

General consensus here is that this is a non-issue because of the aceess requirements, so I am dubious of any security gain whatsoever.

You are now saying that if something is not remotely exploitable, it does not count as a security problem.

The security implication is clear.
If the Pi is turned on but on lock screen, and I have encrypted storage (which is standard in operating systems like Android, but also readily available on the Pi, e.g. when using Berryboot it is a matter of clicking the right checkbox during installation), I have the reasonable expectation that even if someone gains physical access to my Pi, he still is not able to access my files.
But it turns out it is still possible to recover the decryption keys from memory.

You've already had probably the most significant answer in viewtopic.php?f=29&t=231085#p1415516
The SoC doesn't support TrustZone, therefore you're missing many of the significant facets of implementing a secure system.

The Pi is not designed for security applications - it was intended for education.
You can't implement a secure bootloader due to the quirky boot process (the VideoCore VPU boots the ARM cores). There is no boot image signing process, so you can't control what software gets loaded.
Raspbian is not developed with device security in mind - it picks up the security updates that Debian view as required, but it's far from being a locked down system.

Summary: This is not in the bootcode of the existing chips, therefore you are looking at wishlist things for future variants and we don't discuss future products before they are launched. Useful ideas are taken on board, but will not be discussed.

(You're also correct that the bootrom loads the bootloader into the cache, and that code then sets up the SDRAM. There's no easy way around that one with the existing boot process).

… the performance impact is very low, but the security gain is massive. So the ROI is extremly high and thus it should be implemented.

Has one entire actual Raspberry Pi user been negatively affected by this yet? Or is this an Ed Felten/cryogenic cooling/Silk Road takedown thing? A good case and tamper-resistant screws will prevent access to hardware for long enough to ensure that all dynamic RAM is zeroes.

If you're doing darknet or massively valuable transactions, why are you doing it on a computer designed for children's education?

‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

Hmm, thinking about it, that may not work either.
Given the fact that in the past when you switched RAM vendor you also released a new bootcode.bin, I am guessing RAM is enabled by that file on SD card, and access to it is still disabled when the on-chip bootrom is run.

If you are concerned about someone getting access to the contens of RAM keep in mind that "cold boot" isn't the only attack vector. If you have JTAG pins/pads on the board (most SoCs have these and there's some indication they are available on RPi as well viewtopic.php?t=209151) you basically have lost. Most JTAG interfaces allow you to halt the CPU(s) and access memory directly.

OTOH preserving RAM contents across reboots is very helpful when debugging things (eg using ramoops) as is JTAG because it means you can do post-mortem analysis when a system crashed.

So on general purpose systems having all that stuff available makes a lot of sense. If you have very high security requirements you need to look into specialised systems.

Can anyone actually explain why this is a valid security issue? In order to do any of the above, you need physical access to the device, in which case all bets are off anyway.

Not all bets, but it depends on the circumstances and what form physical possession takes.

Imagine if you are an activist and the authorities grabbed your Pi out of your hands while using it. If serious about not letting your data fall into the wrong hands you might have encrypted your SD Card data and have your Pi set up to wipe data and memory unless a secret code is entered regularly, so it would wipe that data soon after you bit down on your cyanide pill.

If that plan succeeds then the authorities are out of luck, even though they have full physical access. They might retrieve some data but probably not all. Once time's up, encryption codes are lost forever and there's no longer access to the data even when that's on a card they hold.

If the authorities suspected the Pi was primed for detonation, one way to get the encryption keys could be to go prepared to use such an attack. Grab the Pi, pull the encrypted SD Card, perform the attack, get the keys, then decrypt the data later. They could also grab whatever data is lingering in memory unencrypted.

Is it a valid security issue ? I would say, yes, but not for most Pi users. And not something worth worrying over or valid enough to justify investing excessive effort to mitigate against.

The security implication is clear.
If the Pi is turned on but on lock screen, and I have encrypted storage (which is standard in operating systems like Android, but also readily available on the Pi, e.g. when using Berryboot it is a matter of clicking the right checkbox during installation), I have the reasonable expectation that even if someone gains physical access to my Pi, he still is not able to access my files.
But it turns out it is still possible to recover the decryption keys from memory.

Just out of interest, is this how its done? ? AIUI, this attack replies on the content of RAM being maintained over a boot. So lets assume you remove the SD card, and have a new card in place that will take over the boot process. Where in the 1GB of memory is the key? Do you then have to check every single 128bit sequence in memory (that's 1024*1024*1024 give or take possible keys)? That's about 125 days of checking at 100 per second. Hmm, that doesn't seem too bad. I guess decent super computer could reduce that quite a bit, and probably are lot of short cuts (e.g. ignore stuff starting on a non-word boundary). Lot of effort though, to crack a SBC. If I were really wanting data to be secure, I'd be inclined to instead of whole disk encryption, use file by file, that way the encyrption key is not in RAM for any length of time anyway.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

If you are concerned about someone getting access to the contens of RAM keep in mind that "cold boot" isn't the only attack vector. If you have JTAG pins/pads on the board (most SoCs have these and there's some indication they are available on RPi as well viewtopic.php?t=209151) you basically have lost. Most JTAG interfaces allow you to halt the CPU(s) and access memory directly.

You do have a point there.
But working with debug interfaces, or accessing memory chips on the PCB directly requires skill, unlike just inserting a memory dumping SD card and getting it to reboot.

OTOH preserving RAM contents across reboots is very helpful when debugging things (eg using ramoops) as is JTAG because it means you can do post-mortem analysis when a system crashed.

Yes, I certainly think ramoops is useful and should be enabled by default too.
But that could work together fine with memory zero'ing by excluding a small range for that.
Can configure the memory range Linux should use for ramoops through device tree.

Last edited by incognitum on Tue Jan 15, 2019 10:28 am, edited 4 times in total.

Just out of interest, is this how its done? ? AIUI, this attack replies on the content of RAM being maintained over a boot. So lets assume you remove the SD card, and have a new card in place that will take over the boot process. Where in the 1GB of memory is the key? Do you then have to check every single 128bit sequence in memory (that's 1024*1024*1024 give or take possible keys)?

The document linked earlier in this thread called "Cold Boot Attacks on Encryption Keys" mentions that an AES key which originally was 256 bit is expanded to a 240 bytes key schedule in memory when it is being used to encrypt/decrypt things (like when your encrypted storage is mounted).
And they wrote a program to spot such structures.

Also I can imagine that when full disk encryption is used the key will live in kernel space, and the region where in memory that will be may be predictable as well, limiting the amount you have to search.

OTOH preserving RAM contents across reboots is very helpful when debugging things (eg using ramoops) as is JTAG because it means you can do post-mortem analysis when a system crashed.

Yes, I certainly think ramoops is useful and should be enabled by default too.
But that could work together fine with memory zero'ing by excluding the range used for that.
Can configure the memory range through device tree.

Anything you do in the boot stage, loaded from some (external) storage device, is too late.

An open source VC4 assembler exists, people implemented a rudimentary open source bootcode.bin replacements that sets up the DRAM controller and boots a kernel from SD card - modifying that to just init the DRAM controller and dump the memory to SD card is something one could do on a boring sunday afternoon when there's nothing interesting to watch on TV.

Unless the boot is secured and the ROM boot code clears the RAM (and of course if there are no debug interfaces available to intercept execution of the ROM boot code) physical access to a device like the RPi will give you rather easy access to the RAM contents.

OTOH preserving RAM contents across reboots is very helpful when debugging things (eg using ramoops) as is JTAG because it means you can do post-mortem analysis when a system crashed.

Yes, I certainly think ramoops is useful and should be enabled by default too.
But that could work together fine with memory zero'ing by excluding the range used for that.
Can configure the memory range through device tree.

Anything you do in the boot stage, loaded from some (external) storage device, is too late.

An open source VC4 assembler exists, people implemented a rudimentary open source bootcode.bin replacements that sets up the DRAM controller and boots a kernel from SD card - modifying that to just init the DRAM controller and dump the memory to SD card is something one could do on a boring sunday afternoon when there's nothing interesting to watch on TV.

Unless the boot is secured and the ROM boot code clears the RAM (and of course if there are no debug interfaces available to intercept execution of the ROM boot code) physical access to a device like the RPi will give you rather easy access to the RAM contents.

so long,

Hias

So effectively, we would need to update the hardcoded bootcode in the SOC to achieve this. (See 6by9's post above about secure boot as well)

Which is not possible without very large sums of money expended.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

To sum up and please correct me if I'm wrong.
1. We must do the RAM zeroing in the Boot-ROM.
2. Boot ROM is not writeable after production process, so any RAM zeroing security measure would mean new Raspberry-PIs.

You're probably currently developing the next Gen Raspberry PI, so it would be possible to make it secure against coldboots. Where do we have to write to that you consider that measure it in your development?

Which is not possible without very large sums of money expended.

Can you explain why this little code change for future devices would cost large sums of money?

So effectively, we would need to update the hardcoded bootcode in the SOC to achieve this. (See 6by9's post above about secure boot as well)

Which is not possible without very large sums of money expended.

Basically yes, but it still is a very incomplete fix so IMO not worth the hassle.

If one is concerned about these kinds of attacks it's better to use something with more sophisticated hardware support, like eg an AMD EPYC system with hardware memory encryption https://developer.amd.com/sev/ - then even physical access to the DRAM should not reveal any data and you can run critical things in isolated VMs with separate memory encryption keys.

To sum up and please correct me if I'm wrong.
1. We must do the RAM zeroing in the Boot-ROM.
2. Boot ROM is not writeable after production process, so any RAM zeroing security measure would mean new Raspberry-PIs.

You're probably currently developing the next Gen Raspberry PI, so it would be possible to make it secure against coldboots. Where do we have to write to that you consider that measure it in your development?

Which is not possible without very large sums of money expended.

Can you explain why this little code change for future devices would cost large sums of money?

Instead of being argumentative would you not be better off buying a different SBC, the Raspberry Pi is not suitable for your needs, period

adieu

My other Computer is an Asus CS10 ChromeBit
https://www.asus.com/uk/Mini-PCs/Chromebit-CS10

For interest, I’ve carried out a few rough and ready experimental measurements on an early Pi1B to get an idea of the scale of the problem. This is done by writing a pattern into a fixed area of memory, powering off and on and reading the memory back to get an idea of how much has changed. These results are for 32 bit words, for 8 bit characters the effective error rate would be lower. The test uses Ultibo to minimise the boot times – up and running in about a second.

The results are, as expected, very temperature sensitive. At a running temperature of 33C the data is essentially gone in under 2 seconds. A brief (unplug-plug) brown-out does show a 99% + retention. Freezing down to -10C shows about a 50% retention after 10 seconds which drops to under 1% by the time the temperature has risen to 5C.
These are worst case tests, any bit error in a 32bit word is treated as a fail. It needs extending to measure bit & character errors and the effect of different test patterns but it gives an idea of the scale of the concern.

Not really an issue for the intended use of the Pi which has never been promoted as a secure platform – apart from which such an attack really needs physical access to succeed (which means all bets are off anyway). So, if your Pi is in an insecure enclosure outside in the middle of Winter somebody might be able to swap the memory card quickly enough to dump the memory (or give it a dose of freezer spray in the Summer).

Can you explain why this little code change for future devices would cost large sums of money?

Because it is almost certain that the design of whatever will become the Pi4 is already at an advanced stage, so it would have to be taken back to an earlier stage and reworked. If the Pi4 is based on existing Pi3 designs (which is not at all certain) it is still expensive to change the hardware compared to re-using an established design.

Any such changes (even if they could be included in Pi5 specifications now, probably before any design work is done) will be evaluated on a cost-benefit basis, having regard to the RPF's mission in education. It is harder to justify changes that are of minority interest but which add cost for educational users. It is quite possible that adding cost will reduce total sales, thus negatively affecting the educational mission. The Pi is not intended to be, nor is it marketed as, a secure computing platform. Those who need that have better options in other market segments.

Of course, we don't know, and those who do aren't telling. We may find, at or after launch, that the Pi4 does support sercure computing....

Can you explain why this little code change for future devices would cost large sums of money?

Because it is almost certain that the design of whatever will become the Pi4 is already at an advanced stage, so it would have to be taken back to an earlier stage and reworked. If the Pi4 is based on existing Pi3 designs (which is not at all certain) it is still expensive to change the hardware compared to re-using an established design.

Any such changes (even if they could be included in Pi5 specifications now, probably before any design work is done) will be evaluated on a cost-benefit basis, having regard to the RPF's mission in education. It is harder to justify changes that are of minority interest but which add cost for educational users. It is quite possible that adding cost will reduce total sales, thus negatively affecting the educational mission. The Pi is not intended to be, nor is it marketed as, a secure computing platform. Those who need that have better options in other market segments.

Of course, we don't know, and those who do aren't telling. We may find, at or after launch, that the Pi4 does support sercure computing....

Of course you're right, designing the Raspberry PI concerning highest security causes high costs. I don't need that.
Booting the Raspberry PI with a small SD-Card image just dumping the RAM contents is very easy. Attacking the Raspberry via JTAG is a much more sophisticated attack. So to secure against this "cold boot SD-Card swap attack" a few lines of code are sufficient. This should be possible with very little effort but gaining a high security plus. As already mentioned this feature may be very important for human righ activists.

Can you explain why this little code change for future devices would cost large sums of money?

Because it is almost certain that the design of whatever will become the Pi4 is already at an advanced stage, so it would have to be taken back to an earlier stage and reworked. If the Pi4 is based on existing Pi3 designs (which is not at all certain) it is still expensive to change the hardware compared to re-using an established design.

Any such changes (even if they could be included in Pi5 specifications now, probably before any design work is done) will be evaluated on a cost-benefit basis, having regard to the RPF's mission in education. It is harder to justify changes that are of minority interest but which add cost for educational users. It is quite possible that adding cost will reduce total sales, thus negatively affecting the educational mission. The Pi is not intended to be, nor is it marketed as, a secure computing platform. Those who need that have better options in other market segments.

Of course, we don't know, and those who do aren't telling. We may find, at or after launch, that the Pi4 does support sercure computing....

Of course you're right, designing the Raspberry PI concerning highest security causes high costs. I don't need that.
Booting the Raspberry PI with a small SD-Card image just dumping the RAM contents is very easy. Attacking the Raspberry via JTAG is a much more sophisticated attack. So to secure against this "cold boot SD-Card swap attack" a few lines of code are sufficient. This should be possible with very little effort but gaining a high security plus. As already mentioned this feature may be very important for human righ activists.

It's a few lines of code BUILT IN TO THE SOC, i.e. hardwired in the silicon itself. So to put that in the current Pi would cost about $500k (the cost of a respin of the die). Doing it in new SOC would be cheaper, but the chip for the Pi4 is at too advanced stage for any respins, so that would be to be done for the Pi5. So that some years away, so in the meantime, I'd suggest human right activists use file by file encryption, which doesn't involve a decryption key being stored in RAM. Or they turn their Pi's off after use. Or store everything in the cloud rather than on SD card.

This attack vector is MASSIVELY overblown. To actual be vulnerable, you need to have the Pi, turned on, with the encryption key in RAM, the assailent need to get to it before the user can turn it off, then remove the SD card, replace with a new one, reboot, then scan the resulting RAM dump to try and find the key. In any place where a human right activist is getting this sort of treatment, it won't matter what is on the SD card, they are stuffed anyway.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."