Cold Boot Attacks on Disk Encryption

[Pit0711]

http://www.ulm.ccc.de/Rheintal/MemoryDump

http://www.freedom-to-tinker.com/?p=1257

:-)

[jimparis]

As far as I've seen, the hypervisor clears RAM at boot before OtherOS is loaded, so it's not possible to run code that would find leftover stuff there -- at least not with an OtherOS-based software-only approach.

[IronPeter]

Video memory is persistent after cold boot. In fw < 2.1 at least.

[gigi]

The most interesting thing is probably a hot dump of the ram modules but of course there are no known information ( correct me if i' m wrong ) about hardware pin out of ram , socket etc. So it's quite difficult , at least for me , to think about a possible setup of a test case.

Gpu changes as already pointed out is not cleared in the context switch between game-os and Otheros if the Gpu has status -32768.

It would be interesting to discuss about that since the Princeton's paper was pretty shocking at least for me , I always tended to believe that in ram data was immediately cleared.

I'd also like a moderator to express his opinion if such thread can be continued or it's too much related to hacking , understanding the strict policies of this forum.

[ooPo]

As long as it is a legal method of information gathering and isn't used for piracy, I have no problems. Other moderators may have stricter guidelines but that's the basic test I use.

[gigi]

fantastic, then any idea? :-) would be very nice to understand if for example,

- Is it possible to setup an environment to dump the operative system while the ps3 is powered on , for me not ( i'm talking about "freezing ram" , phisically remove it and dump it via socket to an external medium ).

- Obtain any "additional" information via rsx fifo on fw < 2.1 , there is much left to do on rsx and i'm so unhappy that I can't use it if I will upgrade to newer firmwares.

On that point there were many topics here , but my personal opinion , remain that Sony sold a console emphatizing it act as a working desktop solution in official presentations as marketing pratice .

When remarkable progress was done on Rsx giving the community a fast desktop on OtherOs , sony removed it without notice ( I know some Sony dev on linux kernel tree would say : you have just to follow the suggestion we give in the kernel and we can change such specs when we want to ... open community eh? bullshit.

Sorry the remark it's few months i was wanted to express my opinion after I heard an incredible amount of nothing from Sony.

So I don't the Rsx development as hacking related to piracy and we should continue to look at Rsx , I can't understand why here the progress stopped .

[unsolo]

I believe a lightening fast desktop can be archived using only spu's and some are actually working on that subject..

[mc]

I would expect any crypto keys to be stored in the local RAM of an SPE running in isolation mode, making them inaccessible both from PPE code and from pin-snooping of the RAM chips.

[gigi]

Mostly I expect the same following secure boot patent , but if it's feasible to setup a test at least we can have some answer. Also the ringbus configuration with APU in isolated mode is for initial setup , in second stage i wonder how things are implemented.

[boxbuilder]

Here is the document about how the cellbe solves the vulnerability to cold boot attacks.
http://www.ibm.com/developerworks/power ... lsecurity/

It seems like since the vram patch allows us to mount vram, why not make a patch which allows us to mount every address visible to the GPU (lv1_gpu_memory_allocate 0 size ?)
EDIT: "mount" meaning see as a disk device, only filesystems are actually "mounted".

Then it may be possible to issue HV calls and look for corresponding changes in the addresses visible to the GPU, this may indicate whether the GPU can directly address other devices.

The only thing that I don't get about the cell security is, how does the authenticated spe program know that the ppe component is not compromised? It's IBM, they must have done something.

EDIT:
{
My reason for wanting access to all devices via RSX is because in case of the slim chance that RSX can read/write the cache on the CELL, then it can scan the CELL's cache for an "ascend to HV mode" instruction, then replace the instructions that follow with a bootloader. It must be done with a USB monitor as the other drivers will be lost, but it sounds possible (Assuming the RSX has read/write to the cache where the instructions are lined up.) If it hangs then just reboot, no brick.

I think killing the HV is much more likely and ethical than breaking the root key, ps3 games will only ever run under HV, and opening the keyvault will make it possible for the HV code to be patched to do bad things.

Frankly I wish sony would give out free firmware which didn't use SPE isolation, and then we could change our root key. No more games/bluerayMovies, no more limitations, no more proprietary firmware, no more worries about opening Pandora's box of warez
}

whatisaname?

______________________________________________________________
Vote Ron Paul for freedom!
watch http://video.google.com/videoplay?docid ... 9643041382