Russel: 1) Global Platform is only about getting applications onto the card. It doesn't say anything about what they do once they are successfully installed so Java Card's file system backdoor would, I suspect, be regarded as "out of scope" by GlobalPlatform folks.
2) Yes, a SIM applet that accesses the backdoor must have the telecom operator's crypto-blessing and be given explicit access to the backdoor by the operator. But isn't this just the point. The telecom operator can, by loading such an applet, perform an end-run around the wishes of (and promises made to) the subscriber. 3) There are a number downsides to the application-centric model of data storage and security: 1 - Each application programmer must also correctly implement security policy. This is not the primary responsibility of the application programmer, the functionality of the application is, and we know that implementation is where most security breaks down. A corollary here is that there is no explicit assurance that implemented security policy is uniform across applets. One may happily give out my telephone number for free whereas another may decide that my telephone number is PIN protected. In fact even after visiting each applet in order to try to PIN protect my telephone number it may be that one or the other of the applets does not offer this option. I am at the mercy of the application programmer who was understandably busy building application functionality and not worrying about providing security options. 2 - Data sharing is much more difficult to both implement and to administer in an application-centric architecture versus a data-centric architecture. Yes, I know all about Shareable Interface Objects and I also know what a pain they are to use and that they open up all sorts of security holes (e.g. A has an approved interface to B but A passes the data onto C which B didn't intend, etc.). See ... http://www.usenix.org/publications/library/proceedings/smartcard99/montg omery.html The practical result is that data is duplicated from applet to applet (each applet will know my name, my telephone number, etc., etc., etc.) and we know where this leads. Furthermore, if I want to introduce a new applet and have it access data in an existing applet, I have to delete and reinstall the existing applet so that it knows about the new applet. 3- Data management and administration is more complex and more expensive. Rather than just updating data in a file, I have to get all the data out of an applet, delete the applet, reinstall the applet and then personalize it with the backed up data. The security that is used to backup the data must of course be provided by the application programmer. A file system is not just an artifact of computing history. It has proven to be a useful concept. Language-based, application-centric approaches to data storage (Smalltalk, Lisp, Mainsail, Oberon, etc.) have done less well on the test of time. IMHO, as always. Cheers, Scott -----Original Message----- From: Dr Russel Winder [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 1:39 PM To: MUSCLE_List Cc: [EMAIL PROTECTED] Subject: RE: [Muscle] Wireless Wallet - Already in Korea Scott, I wonder if there is more to this that at first might appear and that there isn't such a clear backdoor? I cannot imagine the GlobalPlatform people allowing such obvious backdoors. Also it is not in the network operators' interest to have such clear backdoors if they want to sell secure application space on their SIMs which is a must for their future business models. All the TS 102 226 stuff is dealt with using Secured Packets (TS 102 224) which requires a cryptographically supported authentication system. So the access domain packet is happening in a secure authenticated transaction which gives a point at which an access has to prove itself before being able to get at the filestore. To say more at the moment would be to speculate -- I definitely need to investigate this further. Of course the UICC store is not the sensible place for any Java and Java Card applications to store information -- for Java Card or Java applications on a (U)SIM maintaining data objects within the application is the only really sensible secure system. Aha here is a design for a useful SIM-based application -- a secure data store... On Thu, 2004-03-11 at 17:07, Scott Guthery wrote: > Since the backdoor is mandated by the SIM standards, it is true of all > standards-compliant Java Card SIMs. > > ETSI TS 102 226 states: > > "The access rights granted to an application and defined in the access > domain parameter shall be independent from the access rights granted > at the UICC/Terminal interface. > > NOTE: This implies in particular that the status of a secret code > (e.g. disabled PIN1, blocked PIN2, etc.) at the UICC/Terminal > interface does not affect the access rights granted to an application. > > If an application with Access Domain Parameter 'FF' (i.e. No Access to > the File System) tries to access a file the framework shall throw an > exception. > > If an application has Access Domain Parameter '00' (i.e. Full Access > to the File System), all actions can be performed on a file except the > ones with NEVER access condition." > > As you point out this may not be true of non-standards compliant SIMs > but I suspect there are few of those in use. > > You can imagine the surprise of a subscriber when PIN-protected data > shows up on the screen courtesy of a Java applet and the subscriber > knows that they haven't entered their PIN. -- Russel. ==================================================================== Dr Russel Winder, Chief Technology Officer Tel: +44 20 8680 8712 OneEighty Software Ltd Fax: +44 20 8680 8453 Cygnet House, 12-14 Sydenham Road [EMAIL PROTECTED] Croydon, Surrey CR9 2ET, UK http://www.180sw.com _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
