SMS Push Enhancement
Steve at Wind River
SMS Push messages are used to initiate device control functions, which
are critical for both users and operators. Many operators and OEM
venders use SMS Push messages to initiate certain device control
functions, such as the initiation of a firmware update, and services,
as specified as OMA PUSH Application ID.
We would like to introduce a more reliable and secure message handling
process for critical SMS Push messages to AOSP. Wind River has
completed the source code and testing for this proposal, under
collaboration with NTT DOCOMO.
The source code has been uploaded to the AOSP Gerrit review server:
https://review.source.android.com//#change,16610
Currently WAP Push messages are handled by the class WapPushOverSms in
the telephony package. WapPushOverSms broadcasts messages to all
applications that have registered for a message’s content type.
Potentially, a message may be delivered to an unknown application, or
a wrong package may respond to a message, or multiple packages may
respond to a message. Potentially, an unfriendly application may
interfere with important device control messages and/or private
control messages.
This is a known issue among some operators. Currently carriers ask OEM
venders to fix this issue per device. This change introduces a more
reliable and secure message handling for critical SMS Push messages in
the open source code.
Our change is to extend WAP Push Message handling to use a protected
mapping table to distribute certain critical messages only to intended
applications. This extension does not filter all messages or block a
specific port. It does not affect regular SMS messages but only WAP
Push Messages that are listed in the table.
The existing package WapPushOverSMS is extended to use the mapping
table to find a high-priority receiver for a message using the x-wap-
application-id and content type from the SMS header. The high-priority
receiver is called before other processing, and it may choose to
prevent further broadcast of the SMS message. Otherwise, the message
is processed as it is now. Message types that are not registered in
the table will be processed as usual.
The mapping table is not public. It's intended to be updated the same
way that other system components are updated, e.g. via an OTA update
or an app with signatureOrSystem access. Thus, the addition of
priority handlers is under the control of the owner of the system
software. Run-of-the-mill apps cannot install a priority handler.
A signature check only applies to priority handlers. Regular handlers
are not affected. In our implementation, in the table of priority
handlers, there's a per-entry flag that controls signature matching.
If the bit is set, the target handler must have the same signature as
WAPPushManager, which will be signed with the system keys. The
purpose is to make sure that the handler is legit.
A new package, WAPPushManager, provides an interface to add, remove,
or delete entries from the mapping table, protected at the
signatureOrSystem protection level.
WAPPushManager is also optional. If it is not installed on the device,
WAP Push message handling falls back to the existing AOSP code.
We hope that this new enhanced secure message handling process will be
included in the Android Open Source Project.
- Steve
Steve Scalpone
Wind River Mobile Solutions Engineering
firewa...@googlemail.com
were its really reported as a bug?
Basically some use case i mean with an example were operator wanted or
tried and failed to work? I assume few use cases also will give some
more better idea for fitting in this logic/enhancement.
Thanks in advance
Calvin White
The use case that we were working with was using a WAP Push message to
initiate a firmware update. The concern is that there is nothing at
the moment to prevent an application from registering for the
corresponding content-type and then receiving the resulting Intent.
This could interfere with the update process. This enhancement
prevents such interference by allowing system applications to register
priority handlers for these critical messages.
Currently the carriers are aware that this could occur and ask the
OEMs to fix it, this work would standardize the fix.
Regards,
Calvin
Calvin White
Wind River Solutions Mobile Delivery
On Wed, Aug 25, 2010 at 11:23:53PM -0700, firewa...@googlemail.com wrote:
> Appreciate the detailed comment. Could you explain some scenarios,
> were its really reported as a bug?
> Basically some use case i mean with an example were operator wanted or
> tried and failed to work? I assume few use cases also will give some
> more better idea for fitting in this logic/enhancement.
>
> Thanks in advance
>
> On Aug 25, 3:25�am, Steve at Wind River <rascal2...@gmail.com> wrote:
> > Hi Android Contributors,
> >
> > SMS Push messages are used to initiate device control functions, which
> > are critical for both users and operators. �Many operators and OEM
> > venders use SMS Push messages to initiate certain device control
> > functions, such as the initiation of a firmware update, and services,
> > as specified as OMA PUSH Application ID.
> >
> > We would like to introduce a more reliable and secure message handling
> > process for critical SMS Push messages to AOSP. �Wind River has
> > completed the source code and testing for this proposal, under
> > collaboration with NTT DOCOMO.
> >
> > The source code has been uploaded to the AOSP Gerrit review server:
> >
> > https://review.source.android.com//#change,16610
> >
> > Currently WAP Push messages are handled by the class WapPushOverSms in
> > the telephony package. WapPushOverSms broadcasts messages to all
> > applications that have registered for a message?s content type.
LocalWords: Aug