[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kvm-interest
Subject:    Re: AW: MIDP 2.0 MIDlet Signing
From:       Pubudu Chandrasiri <Pubudu.Chandrasiri () VODAFONE ! COM>
Date:       2003-07-23 12:36:20
[Download RAW message or body]

Hi Benjamin,

If you read the MIDP 2.0 security RP, attached as an addendum to the spec,
you will find the most likely security policy for MIDP 2.0 devices in the
GSM and UMTS worlds.

Regards
Pubudu

-----Original Message-----
From: Jonathan Knudsen [mailto:jonathan.knudsen@SUN.COM]
Sent: 18 July 2003 22:14
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Re: AW: MIDP 2.0 MIDlet Signing


Hi Benjamin,

Thanks for the nice words.

Yeah, the specification is deliberately vague about the implementation
of protection domains, which allows manufacturers and carriers
considerable latitude in deciding what to do. Honestly, I have no idea
what's coming, but I can imagine a spectrum of possibilities.

At the most restrictive end of this spectrum, a manufacturer/carrier
could define a single trusted domain for MIDlets signed by the carrier's
own key. In this scenario, developers would have to apply to the carrier
to get a developer key, or to get their applications signed (probably
certified, too) using the carrier's key. That's the only path into the
trusted domain; everything else is untrusted, and most likely the
untrusted domain just asks the user for permission to access the network
(and whatever else).

At the most open end, the device could ship with the standard suite of
CA certificates and allow the user to map signed suites into the trusted
domain based on the signing certificate. This would allow developers to
get certificates from standard CAs and deploy to devices without regard
to manufacturer or carrier.

My guess is that initial MIDP 2.0 implementation will have some mix of
these characteristics, then eventually the industry will gravitate
toward the more open end of things. But take it all with a grain of
salt. I have no idea what's going to happen.

Regards,
Jonathan

Benjamin Broll wrote:
> 
> Hi Jonathan,
> 
> thanks fort he fast reply and the well-written article. It's much easier
> to follow the security scheme reading your article than reading the spec
> ;-)
> 
> Regarding the protection against changes of the MIDlet-Suite that's what
> I expected - I just could not find it explicitly stated in the spec. But
> I still have a question about the protection domains:
> 
> In your example and in the wireless toolkit it is pretty easy to assign
> a protection domain to a key pair. However, in a real-world situation
> things won't be that easy. To gain access to a certain protection domain
> on a certain phone, your key pair has to be signed using a key of the
> phone manufacturer - is that correct? Besides that, the phone
> manufacturers will have to provide some information on their embedded
> protection domains so that a company can apply to be assigned to one,
> right?
> 
> Thanks for an answer in advance,
> 
> Benjamin
> 
> -----Ursprüngliche Nachricht-----
> Von: A mailing list for KVM discussion
> [mailto:KVM-INTEREST@JAVA.SUN.COM] Im Auftrag von Jonathan Knudsen
> Gesendet: Freitag, 18. Juli 2003 20:02
> An: KVM-INTEREST@JAVA.SUN.COM
> Betreff: Re: MIDP 2.0 MIDlet Signing
> 
> Hi Benjamin,
> 
> You're right, the signature does protect the MIDlet suite from being
> modified; if any part of the MIDlet suite changes after the signature is
> generated, the new signature won't match the old one.
> 
> I think the primary purpose of signing is so users can trust the stuff
> they're downloading. For example, if I get a MIDlet suite that's signed
> by somebody I trust, then I'm pretty sure it's not malicious code and
> won't do mean stuff to me or my phone. The data integrity provided by
> the signature is part of this trust.
> 
> I hope this helps. I have an article that talks about protection domains
> and permissions that you might find helpful. It covers signing MIDlet
> suites with the J2ME Wireless Toolkit.
> 
> http://wireless.java.sun.com/midp/articles/permissions/
> 
> Regards,
> Jonathan
> 
> Benjamin Broll wrote:
> > 
> > Hi everybody,
> > 
> > I'm currently reading the MIDP 2.0 spec's parts on signing MIDlet
> > Suites. The notion of signing a MIDlet implies to me that after having
> > been signed the MIDlet should be protected against changes: whenever
> the
> > JAR gets changed by somebody, the phone should not authenticate the
> > MIDlet anylonger.
> > 
> > However, I was not able to find anything about this topic yet. Does
> > anybody have better knowledge than me and cares to share it?
> > 
> > Cheers,
> > 
> > Benjamin
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: A mailing list for KVM discussion
> > [mailto:KVM-INTEREST@JAVA.SUN.COM] Im Auftrag von James Allen
> > Gesendet: Freitag, 18. Juli 2003 18:37
> > An: KVM-INTEREST@JAVA.SUN.COM
> > Betreff: Upcoming Sun ONE Studio 5, Mobile Edition Early Access
> Program
> > 
> > Dear Customer:
> > 
> > We're extending an offer for your participation in the upcoming Sun
> ONE
> > Studio 5, Mobile Edition Early Access test program which we're
> planning
> > to make available this summer.   Our Early Access program is by invite
> > only and participation will be limited based on our capacity to
> provide
> > service and gather feedback from the participants.
> > 
> > WHAT IS SUN ONE STUDIO Mobile Edition?
> > 
> > Sun ONE Studio 5, Mobile Edition is the next release of a Java
> > Integrated Development Environment (IDE) designed for creating
> > applications
> > for Java technology-enabled mobile devices using the Java 2 Micro
> > Edition
> > CLDC/MIDP platform.   It is based on the NetBeans 3.5 tools platform.
> > Sun ONE Studio 5, Mobile Edition is introducing support for MIDP 2.0
> and
> > a new
> > Wireless Connection Wizard (enabling much easier integration between
> > J2ME and
> > J2EE aplications).
> > 
> > New features and functionality coming in Sun ONE Studio 5, Mobile
> > Edition include the following:
> > 
> > * Improved IDE start-up time and UI performance
> > * Support for MIDP 2.0
> > -Signing MIDlet suites
> > -Push registry development
> > -OTA testing
> > * Improved MIDlet suite editor
> > * Ability to directly import projects from J2ME Wireless
> > Toolkits
> > * New Editor toolbar
> > * JavaDoc available in code completion
> > * Background compilation
> > * New Wireless Connection Wizard for developing networked
> > applications
> > 
> > and much more...
> > 
> > EARLY ACCESS PROGRAM BENEFITS:
> > 
> > As an Early Access participant, you gain access to the pre-release
> > version of the product and are a key contributor in testing features
> and
> > reporting
> > bugs and problems.  We encourage you to report your feedback regarding
> > the quality
> > and performance of the software.  You will be provided with support
> > during this
> > program to assist you with problems that you may encounter.  As with
> any
> > Early Access
> > Program, there are going to be bugs in the software and we cannot
> > guarantee a fix
> > or patch for specific bugs.
> > 
> > The following are requirements for all selected EA participants:
> > 
> > - Ability to download product software from a website
> > - Accept the "Non-Disclosure Agreement" upon download of the
> > product
> > - Accept the "Pre-Release License Agreement" upon download of
> > pre-FCS product
> > - Install the product within 3 days of the program starting and
> > begin testing
> > - Submit Installation & Usage reports via the website
> > - Log all software problems and bugs via the support page.
> > 
> > WHERE TO APPLY:
> > 
> > If you would like to participate in the program, please fill in the
> > application form at:
> > 
> > http://access1-dev.sfbay.sun.com/s1s5me-ea/ca-s1s5me/
> > Login ID   : S1S5MeGo
> > Password   : s5MEnow!
> > 
> > After review of your application we will be in touch to let you know
> if
> > you have been accepted to participate in our program.
> > 
> > Sincerely,
> > 
> > Tammy Tennier                   Sun Microsystems, Inc.
> > Program Manager,                16 Network Circle, M/S  UMPK16-303
> > Sun ONE Studio Tools            Menlo park, CA  94025  USA
> > 
> > email: tammy.tennier-nuncio@sun.com
> > phone:  +1 650 786 6739 (direct line)
> > 
> > --
> > ==============================
> > James Allen
> > Sr. Product Marketing Manager
> > J2ME Platform Marketing
> > Sun Microsystems, Inc.
> > 
> > email: james.allen@sun.com
> > voice: +1 408-276-5596
> > 
> > 
> ========================================================================
> > ===
> > To unsubscribe, send email to listserv@java.sun.com and include in the
> > body
> > of the message "signoff KVM-INTEREST".  For general help, send email
> to
> > listserv@java.sun.com and include in the body of the message "help".
> > 
> > ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙
> > To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> > of the message "signoff KVM-INTEREST".  For general help, send email
> to
> > listserv@java.sun.com and include in the body of the message "help".
> 
> ========================================================================
> ===
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST".  For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
> 
> ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙
> To unsubscribe, send email to listserv@java.sun.com and include in the
body
> of the message "signoff KVM-INTEREST".  For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

 =========================================================================To \
unsubscribe, send email to listserv@java.sun.com and include in the body of the \
message "signoff KVM-INTEREST".  For general help, send email to \
listserv@java.sun.com and include in the body of the message "help".


[prev in list] [next in list] [prev in thread] [next in thread]