×

Discussion Board

Results 1 to 4 of 4
  1. #1
    Registered User
    Join Date
    Mar 2009
    Posts
    2

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

    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.

  2. #2
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

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

    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.

  3. #3
    Registered User
    Join Date
    Mar 2009
    Posts
    2

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

    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

  4. #4
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

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

    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.

Similar Threads

  1. Replies: 19
    Last Post: 2009-01-23, 12:41
  2. cannot read data written over BT by 6260/6600 on a linux box
    By fahadkhowaja in forum Mobile Java Networking & Messaging & Security
    Replies: 0
    Last Post: 2005-07-21, 13:54
  3. Midlet using a default Access Point
    By fboya in forum Mobile Java General
    Replies: 6
    Last Post: 2003-12-23, 09:58
  4. Midlet using a default Access Point
    By fboya in forum Mobile Java Networking & Messaging & Security
    Replies: 0
    Last Post: 2003-07-03, 18:53

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×