On 2012-09-29 09:01, Frank Cusack wrote: > On Fri, Sep 21, 2012 at 11:58 PM, Andreas Jellinghaus <andr...@ionisiert.de > <mailto:andr...@ionisiert.de>> wrote: > > > Am 20.09.2012 21:06 schrieb "Anders Rundgren" <anders.rundg...@telia.com > <mailto:anders.rundg...@telia.com>>: > > > > > > > http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html > > > > Very interesting IMHO. > > Agree, thanks for sharing. > > > > > > According to the author SD-slots are becoming exceptions also for > Android so this is > > probably what most people will be dealing with. > > I think he is also over optimistic with multi applications on a Java card > SE, but we will see. > > I didn't catch any references to that in the linked article, but if I missed > it or he discusses it elsewhere, I agree. Certainly on an android phone I > don't believe we'll ever see the day when the user can install his own > application on the phone SE.
Right. There is no point in installing applications in the SE; applications are installed on top of the OS. The SE only needs to keep keys (like smart cards in reality do ..) . Keys OTOH will presumably be possible to deploy by anybody the day Google dumps GlobalPlatform. Anders > > On Sat, Sep 22, 2012 at 1:18 AM, Anders Rundgren <anders.rundg...@telia.com > <mailto:anders.rundg...@telia.com>> wrote: > > I even wonder if the SE needs to host "applications" at all. IMO, it > would be enough > if the SE hosts keys and associated attributes while the applications > either rather run at OS-level > as trusted processes like PIN input etc. or as standard applications. As > far as I understand > the Wallet is just an Android "App" that is trusted by the SE. > > > Indeed, the SE need not host applications, but it depends on your > application. For example a wallet (of the digital cash variety) needs to run > code, not just host keys. The Google wallet isn't digital cash but it's > still an SE applet, not an Android app. (So your understanding is wrong.) > > In my mind keys could optionally contain application-oriented ACL telling > which > applications they trust so that even if you install a "bad" App, it would > for > example not be able to use your bank or eID-key in the background. > > > ACL would however be at the mercy of the phone OS, so you've now expanded the > trust boundary so that kind of control defeats the purpose of an ACL. Or > perhaps you have confused me here with "App": if you meant applet that runs > on the SE, then in that case ACLs are useful, however since you have to > interact via the phone you are still at the mercy of the phone OS. > > On Sat, Sep 22, 2012 at 3:41 AM, Andreas Jellinghaus <andr...@ionisiert.de > <mailto:andr...@ionisiert.de>> wrote: > > I must admit I don't know how many apps are managed and seperated. given > the restricted resources a smart > card has, I assume there is a master key that creates contain of specific > sizes/dimensions/... and the app is > loaded into such a container, limiting it and reserving the unallocated > space for further applications/containers? > > > That's exactly right. > > Is there a standard on doing this, or is it all JCOP magic under NDA? > > > It's part of Global Platform. > > On Sat, Sep 22, 2012 at 8:27 AM, NdK <ndk.cla...@gmail.com > <mailto:ndk.cla...@gmail.com>> wrote: > > In my mind, the SE should take over display and touch controller by > hardware means, so absolutely no app can snoop user input or fake it. > > > I agree. > > Too bad seems nobody really *needs* that level of security... > > > I disagree, we all NEED that level of security. It's just that security > isn't a mature thing yet so we're just not there yet. Note that Intel and > ARM both have such technologies today. > > On Sun, Sep 23, 2012 at 2:52 AM, Andreas Jellinghaus <andr...@ionisiert.de > <mailto:andr...@ionisiert.de>> wrote: > > - cards were incompatible forever, but now mostly JCOP survives and > everyone else stopped improving their cards? I haven't seen many new card > operating systems released in the last years at least. and at least for small > developers I'm not aware that you can buy other java cards than JCOP. > > > There are a small but reasonable number of smart card OSes you can buy today. > There aren't any that small developers can work with, but that's just a > consequence of how that market works and it isn't going to change. > > And JCOP again is a prime example of a NDA thing, not a standard, right? > or did it improve? > > > JavaCard is a standard. JCOP is an implementation of that standard. > > On Thu, Sep 27, 2012 at 12:37 PM, NdK <ndk.cla...@gmail.com > <mailto:ndk.cla...@gmail.com>> wrote: > > I knew something that didn't need "trusted software" (in the PC) should > exist. And Finally I found it: > http://www.ftsafe.com/product/epass/interpass > Seems quite near to my idea of a "really-smart card": big display to > show transaction details and button to review/confirm/cancel (and, I > hope, to insert a gesture that replaces the PIN...). > Just evolve that a bit and it's perfect :) > > > I agree, it's close. Not that I've contacted them, but I doubt it's an > actual shipping product. > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
