On Fri, Sep 21, 2012 at 11:58 PM, Andreas Jellinghaus <andr...@ionisiert.de>wrote:
> > Am 20.09.2012 21:06 schrieb "Anders Rundgren" <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. On Sat, Sep 22, 2012 at 1:18 AM, Anders Rundgren <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>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> 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>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> 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
