Update on MExE security

Source:	Vodafone 

The sense of the introduction and points 1 and 2 below formed a draft LS from MExE to S3 (written by the S3 rep to MExE).  MExE however did not wish the LS to be sent.  The draft LS and some further points therefore form this update on MExE security to S3 from the S3 rep (Tim Wright, Vodafone).
Vodafone notes that at their plenaries in August (3-6, Sophia Antipolis) S3 and ETSI SMG10 agreed that S3 would be responsible for the security of MExE release 99 but that SMG10 would be kept informed. Vodafone welcomes this clarification of responsibility and would like to take advantage of it by formally asking S3 to conduct a security review of the present state of MExE release 99 security, as given in the latest version of 23.057, the MExE release 99 stage 2, version 1.4.0, which is attached.  It is appreciated that ETSI SMG10 has a representative within MExE but believes that S3 should take collective responsibility for the security of MExE release 99.
S3 should note that work on using the SIM to provide security services as requested by SMG10 in SMG10 AP99060 (approved by SMG10’s plenary in Stockholm, March 1999) has begun in earnest within MExE, with LSs and CRs sent to ETSI SMG9 and 3GPP T3 for changes to respective (U)SIM specifications.  Details on the use of a SIM certificate by MExE can be found in section 8.5.  Other SMG10 requirements in SMG10 AP99060, such as mandatory support of “one shot” permission (now referred to as single event permission) and the retention of three trusted execution domains were also met by the approved release 98 version of MExE and have been retained within release 99.
In addition to a general review, S3 are asked for guidance on three specific points.
1.	Attention is drawn to section 8.2 of 23.057, the MExE “security table”.  This lists the actions that applications in the operator, manufacturer and third party domains (signed applications whose digital signatures can be verified by certificates which can in turn be verified using respectively operator, manufacturer and third party root public keys) are allowed or not allowed to perform.
The comments below mainly relate to MExE classmark 2 (Java) though the principles have relevance for MExE classmark 1 (WAP) 
Some history of the security table might be helpful.
Initially (sometime prior to the approval of MExE release 98), the only actions that could be performed by MExE executables within a particular domain were those actions specifically permitted by the security table.  That is, actions not listed in the security table could not be performed by any MExE executable, trusted or otherwise.  The onus was therefore on those who wished certain actions to be performed to ensure that these actions were listed in the security table.
It was felt that this would prevent innovative manufacturers and application writers from writing useful (and benign) applications that would perform actions that the MExE group had not thought of.  It was therefore agreed that actions not listed in the security table could be performed by any trusted executable.  At this time there were a defined set (mainly from SUN) of Java API’s (Application Programming Interfaces, a defined set of function and parameter definitions that can be used by high level programmers to call lower level Java functionality and therefore the set of actions that could be performed by MExE was still demarcated in some sense.
Just before approval of release 98, the requirement to use a defined set of API’s was removed, to reduce reliance on SUN, and again, not to stifle manufacturer innovation.
This means that in theory, there is no specified limit on the actions that can be performed by MExE executables, save those specifically forbidden by the security table.  Concerns have been raised over the security implications of this.
There is a proposal within MExE that the actions that can be performed by trusted executables are those that fit within a category within the security table (and where the action is allowed for the relevant domain) rather than those specifically listed in the security table.  This proposal, though with merit, relies on manufacturers and application writers correctly interpreting what is within the scope of each category in the security table.  Some within MExE have opposed the proposal on the grounds of the stifling of innovation as has been mentioned before.
An alternative is to stick with the release 98 position and that concerned parties make sure that sensitive actions are suitably forbidden or restricted in the security table. The onus in such a case would therefore be on those who wished that certain actions could not be performed by MExE executables to ensure that these actions were specifically forbidden in the security table by all, or the appropriate execution domains.  S3 should note that this would mean the table need only consist of restrictions, with a resulting increase in its manageability.
It should be noted that an application writer can only use API’s that have been written by a manufacturer or a third party (such as SUN or IBM) and that the writing of such API’s is a considerable task.  The swift writing of API’ to perform rogue actions is therefore not possible and, if a manufacturer decided to circumvent the security table in some way, this would have to be a considered and significant decision.
S3 are asked to consider the issues presented above, and to present their conclusions along.  In particular, S3 are asked to consider whether actions not listed in the security table are allowed by trusted MExE executables (the importance of the security table is therefore primarily as a table of “No”’s) or not allowed (the importance of the security table is therefore primarily as a table of “Yes’s”).
2.	External port access.  Access by MExE executables to external ports on the ME (for instance to the infra-red access port (“IrDa”) or Bluetooth) is currently not listed in the MExE security table and is therefore allowed by trusted MExE executables by default.  MExE can see clear use cases for access to external ports by MExE executables, for instance the use of Bluetooth for synchronisation of phone and PC address books.  However, security concerns have also been expressed within MExE on the use of external ports, for instance, access to a GPS receiver attached to a MExE ME would allow a MExE executable to circumvent any security constraints on MExE access to location information, or, using a second phone that was configured to make calls as directed by an insecure Bluetooth link, a MExE executable could circumvent constraints on that executable’s ability to make calls within the MExE environment.  S3 are asked to comment on this issue.
3.	At their most recent meeting, MExE approved additions to the draft release 99 stage 2 giving access to the screen and keyboard to untrusted (i.e. unsigned) applications.  It was claimed that such functionality was already allowed to untrusted applications in the approved release 98 stage 2 and that the additions merely clarified this.  It was the S3 rep’s view that such access was only available to untrusted applications as part of a browser session, that is, unsigned applets and WMLScript  could run as part of a browser session, as applets can as part of a PC browser session, but that applets, applications or scripts could not run outside a browser. .
Leaving this argument aside, the MExE stage 2 now allows long lived untrusted applications on the terminal to access the screen and record input to the keyboard.  This would seem necessary for the games market that is said to be an important part of the untrusted domain market, but there are clear fraud risks.  An application could send bogus messages to the screen asking for security PINS and passwords to be entered or could record such entries and any other keyboard entry, for instance numbers dialled, when they are made legitimately by the user.  The application could then ask the user (untrusted applications cannot send SMS themselves) to send an SMS (perhaps using the “you have won a car” trick) which would contain the record information.
S3 are asked to weigh the value of an active market in untrusted third party applications against the  fraud risks and relay their conclusions to MExE.

S3 should respond to these questions and with regard to their review of the general level of MExE security with a formal liaison statement to MExE (TSG T, WG2, SWG1).