Private folder is not really private
Hi,
I am talking about the data caging model of Symbian OS. It is clear that the \private folder fits well to the sandbox model, i.e. the application is protected in run time. But my question is:
1> can we store some sort of persistent data in the private folder?
I think yes, the data created in previous session can be reused in the next session.
2> Is it true or not the data stored in \private folder still can be siphoned off without permission of the application, its true owner?
Some possibilites are:
- A kind of file browser app with AllFiles capability can copy data from \private folder.
- The owner of device can read data by the backup process. Thus, encryption of data in \private folder is useless, user can mount an off-line attack.
In short, private is not really private.
Does anyone know any API that can help us to encrypt data in \private folder, the key will be hold BY OS only and return to the application upon request. Because OS must verify and authenticate the application first anyway. In other words, even the owner of device, with malicious intention can not read a sh from the \private folder because s/he can not find the key stored anywhere in the device.
Did i miss smt?
Thanks
Re: Private folder is not really private
Hi vanvu76,
I see your point but in answer to your questions:
1) Yes as you surmise you can store persistant data in your private directory.
2) Yes and No
- Executables with the AllFiles capability can indeed read the contents of another process' private directory but access to this capability is extremely restricted. An application developer would have to gain permission from each individual phone manufacturer to get AllFiles and would have to have extremely good reasons to do so. Therefore it is a minimal security risk as believe me unless you are a major anti-virus vendor or in bed with the manufacturers in some other way you just wouldn't get this.
- What gets backed up depends on how you as an application developer have configured the backup script. If you have data that you want to explicitly exclude you can do something like this in your xml file:
<passive_backup>
<include_directory name="\">
<exclude name = "\mysecretdata\"/>
</include_directory>
</passive_backup>
Where mysecretdata is a directory with the data you really don't want to leave the device.
So I think the 'private' mechanism does work in this sense. However, I am not familiar with encryption on Symbian so I am sure someone else can answer that question if you feel you still require it?
Kind regards,
Andy
Re: Private folder is not really private
Thanks Andy,
i deliberatedly raise this issue as i feel that it's hard to write a cusmtomized DRM solution without hacking deep inside Symbian OS and *in bed* with the OS vendor.
For example, the DRM solution from Nokia can store safely their key (right object) in some protected internal phone memory area:
[url]http://discussion.forum.nokia.com/forum/showthread.php?t=94705&highlight=private+folder[/url]
Sure no application can reach this sort of *private* folder. But only the Nokia DRM agent, which has been released inform of OMA DRM CAF Agent API know a secret protocol to access this folder. More important, no kind of data backup tool developed by 3rd party can do the same thing as they have no way to read phone memory??
Sorry, i did not mean to offend Nokia developers. We are very interested in hearing how to extend our homemade DRM solution based on the CAF Agent API class.
Cheers/
Re: Private folder is not really private
Hi Vanvu,
No offence taken! In fact I agree with you entirely about the pitfalls of S60 development particularly in the DRM domain. Its not easy to get in bed with any of the manufacturers (esp. Nokia) unless perhaps there is some obvious benefit to their business or something that would add value to their handsets (personal opinion).
Best of luck,
Andy
Re: Private folder is not really private
Note also, that \private is not private, if it is on a memory card (instead of the phone memory, C-drive), and you put the memory card in a different device, or access it via USB mass storage mode from a PC.