Data caging: how does it prevent a native app in C++ access data written by a MIDlet?

[mpeivrsn]

I have a basic question, and assumed the answer is yes but I cannot find very explicit languages in Symbian OS security doc for this:

Is is true that a native app in C++ in Symbian cannot access data written by a MIDlet in Java ME in a Symbian 9.x device?

I am not sure how application IDs are associated for the OS to determine the privacy and capability across two programming environments.

An application in SIS / C++ is identified by SID. When Java application MIDlet is used, MIDlet is up to the Java ME (AMS) to recognize - signed jar file is authenticated and then traced.

(1) Does Symbian OS treat Java ME entirely as one process /or application? If so, then it delegates access permission to the Java ME, and it is up to Java ME / AMS to do next level of file protection in its own Java ME meta private area.

In other words, when a MIDlet writes a file to system, is the file associated with entire Java ME from OS's perspective? I assume that some way Java ME passes the MIDlet ID to Symbian OS so that it knows it is from a distinct app. Two MIDlets would be considered different apps in OS level, and different from any other native application in C++.

(2) When a MIDlet writes data to Java RMS in non-shared mode with other MIDlets, how does it prevent a native application to read the RMS data? RMS data seemed to locate in DBMS cage (DBMS server private area). I assume that a native application in C++ with UserReadData capability can access DBMS, reading the RMS data, and deserialize to acquire any secret that a MIDlet writes. This is similar to contact database access approach. I am looking for preventions that a native app cannot read data written by a MIDlet's in either file system (\private\xxx) or RMS.

Thanks for confirmations on the questions and reference documents that explicitly talk about the cross environment protection.

[grahamhughes]

This is not quite a "basic question"...

I'm afraid I can't specifically answer your questions regarding the internals of Symbian's JVM. I can tell you, if you want data in RMS to be secure, you should encrypt it. Nothing in the CLDC or MIDP specification state that information stored by a MIDlet should be secure at the native level, only from other MIDlets (and that is handled by the JVM, it doesn't require operating system support).

Hope that helps.
Graham.

[mpeivrsn]

Hi Graham,

Thank you very much for the input. Agree that encryption is the best but there is usability concerns involved if a encryption key is needed. I like the data caging idea for its purpose to mitigate malware despite it isn't 100% reliable (it was hacked). I was wondering how the original data caging design considered this across environments. It looks that the design and J2ME enhancement in Symbian 9.2 tried to offer a full solution. I read this document that describes the changes in J2ME to support data caging in OS level but it isn't explicit on whether the RMS is protected.

http://www.symbian.com/developer/tec...e.platsec.j2me

"J2ME

The following list is a summary of the changes made to the J2ME subsystem to implement Platform Security:

*'Caging' of all binaries and sensitive system and user data in private areas so that they are only accessible to their owning process. Shared RMS databases are located in the DBMS data cage.

*The Java MIDlet installer now installs JAD and JAR files to the Java VM's private area.
"

So I am still hoping that someone can help on what the first bullet point above implies for an native app's access to data written by a MIDlet.

Thanks again.

- Ming

[grahamhughes]

This is an interesting question! :-)

I shouldn't be attempting to answer it, as Symbian isn't my area at all.

What you don't say is, the level of security actually required. Even some fairly simple encryption (hard-code the key into the app, or generate one randomly and store it with the data) would stop most malware attempts to (for example) pick up a 16 digit string that conforms to a credit card number. Of course, if you could decompile the app, you could get the means to decrypt the data easily.

(Incidentally, if you don't encrypt the data, it can be relatively easy to convince the phone that it is installing an "upgrade" to an existing app, which will then have unrestricted access to that app's RMS.)

From the "data-caging" issue... and I must confess this is a new level of Symbian internals for me... it appears that MIDlets have their own UIDs, so are treated as separate entities from a security perspective (not one shared UID for the whole Java world). In fact, a MIDlet suite (JAR file) has one UID, and all the MIDlets it contains have individual UIDs. RMS will be stored at the suite level, since all MIDlets in the same suite share the same RMS. The article here does not relate to data-caging, but does explain something of how MIDlets appear in Symbian's application-space.

If you want the gory details of Symbian's bowels, then the Symbian forum would be the place to post, I think.

Cheers,
Graham.